I'm moving Avaya CMS data from Informix to SQL Server. I have several data flow tasks - one per table, and some of them work fine in any circumstance, while other work fine when executed manually from Integration Services, but will produce different results when run via SQL Server Agent.
I created a new package just to test the root.hvdn table (phone data summarized by the half hour). Avaya says the table is supposed to be keyed on row_date, starttime, vdn (the internal number - similar to extension) and vector; in truth, there are some duplicates, but with valid (i.e, different, call data - probably for a call that crosses an interval). The row_date and vdn fields won't map directly, so they go through a converstion where the row_date converts to DT_DBDATE and the VDN to DT_STR.
The next step is to see which of the Informix records have been previously imported, so it goes through a lookup transformation matching the coverted row_date and vdn, along with the vector and start time against a SELECT DISTINCT of the same fields in the destination table (which eliminates the dupe keys). So, it there's no match, the Informix data goes through a record count to variable (for the sucess email).
The final step is an OLE DB Destination.
When executed through BIDS or the deployed package on Integration Services, the package runs fine. When I schedule it or run it from SQL Server Agent it runs, but inserts a zero length value into the vdn field - every other field is fine. In the version of the package with multiple data flows, some tables update correctly every time, and others have this same type of error. It's as though the conversion works correctly in BIDS, but when running from SQL Server Agent, the vdn is converted to a zero length value, which is a no match and results in an append of the entire record set, but without the vdn.
I've reduced the number of candidate records from Informix by limiting it to row_dates greater than yesterday. That just gives me fewer appends with zero length vdns. I don't want to truncate the destination table because I need to retain records that Informix has previously deleted - it maintains a two-month history, and I need to go back at least two year (eventually).
I'm at a loss. The only thing I can think of is that the destination vdn field is Char(7), but I'm not sure.
Suggestions? Insights?
Tim Mills-Groninger