Dummy Bindings Table

In the solution I describe in the main article, I used the destination Products_TypeN dimension tables as the bindings tables in the Data Driven Query (DDQ) tasks. Because the dimension tables don't contain bit columns that indicate an attribute change, you have to use tricks such as sending a -1 as the attribute's value to convey the fact that an attribute hasn't changed. Alternatively, you can create a "dummy" (empty) bindings table in the destination system with a structure that's identical to the Prod_log source table and refer to it on the Bindings tab of the DDQ task's Properties dialog box. The queries that you write in the Queries tab can be issued against any table in the destination system, not just against the table referred to on the Bindings tab. Using a dummy bindings table that has the same structure as the Prod_log table lets you map the parameters to the bit columns that indicate whether an attribute changed, without the need for any tricks. In the main article, I chose not to use the dummy bindings table to demonstrate some tricks you can use when source and destination table structures are different. However, I strongly advise you to use the dummy table solution in your production system because this way, the solution is much easier to maintain than when you use the destination table itself.