how to write query in OLE DB Command or oledb destination (data access mode – sql command) to insert data to partition view from table/view.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
A Partitioned View is something I had no experience with prior to this question. Using the definition provided in the linked article, I came up with this schema and a sample insert to verify I knew I was doing.
I rolled the transaction back so I had no data in my
dbo.Year1998Salesview. I then created a new SSIS package. The fact that I used SSIS for SQL Server 2012 will have no bearing on the results, the configuration will be the same.I created a new package, added a data flow, added an OLE DB Connection Manager and within my Data Flow I have an OLE DB Source wired to an OLE DB Destination.
In my source, I used the same query as in my SQLFiddle demo
I selected
dbo.Year1998Salesas the destination and viola, it works. Actually no, it didn’t to my amazement. What worked within SSMS errors out in a data flow.Resolution
The telling portion of this error message is the “target of a bulk operation.”
A Data access mode of
Table or view - fast loadorTable name or view name variable - fast loadwill result in a bulk insert into the table and generally speaking that is something you will want. However in this case, that isn’t possible so one must use the RBAR (row by agonizing row) version of a destinationTable or vieworTable name or view name variable.That does work and for smaller data sets, that would be my approach.
Alternative 1
Completely bypass the logical construct of the view and recreate the logic with a conditional split and write to N tables. This would allow you to use bulk updates to the table. However, there’s a not insignificant cost associated with replicating that business logic into your package and further maintenance on the package to keep the two in sync. Heaven help you if the logic gets changed in the underlying view and those changes aren’t propagated to the package or ported incorrectly. I would not go this route unless I had a bullet-proof business reason for doing so.
Alternative 2
Stage your data. Instead of writing to the partitioned view, write all the data to a staging table in the data flow. Immediately after the data flow, have an Execute SQL Task that pushes the data from the staging table into the View.
While I don’t know for certain, my assumption is that this will perform better than Alternative 1 or the original resolution but have not tested. I also don’t list this as the primary resolution because I know in some places, like where I work, creating a new table can be rather controversial.