Hi,
With version 6.0 of TD we are considering moving our SQLServer connectivity from ODBC (router SQLODB32) to OLE DB SQLServer native client.
With OLE DB connectivity, is there an equivalent setting to the SQL.INI settings of:
setzerolengthstringstonull
longbuffer
At this point I haven't been able to find anything in the OLE DB documentation that replicates these settings.
Regards,
Dion
Migrating ODBC to OLE DB
Re: Migrating ODBC to OLE DB
Let me ask internally about this, Dion. In the meantime, I do see a section called "OLE DB Consumer" in the TD ebook, dev.pdf. An online version of that section is available
Re: Migrating ODBC to OLE DB
Got some info. for you:
longbuffer -- our router developer let me know that: "Longbuffer shouldn’t be needed– it’s a router-specific thing."
setzerolengthstringstonull -- I saw a very old TD defect about this setting item and OLE DB. It was closed with no fix/no change because of the use of STRING_NULL.
Defect title was -- I'll put in bold how to simulate this with OLE DB:
"TD OLEDB consumer, inserting/updating row via a data field or a string variable, the field in the table will contain '' (non NULL) value instead of the expected NULL for back-end like SQLserver, setting explicitly the string to STRING_Null avoids this."
Thus,
Set sVar = STRING_Null
is how to code this for OLE DB.
longbuffer -- our router developer let me know that: "Longbuffer shouldn’t be needed– it’s a router-specific thing."
setzerolengthstringstonull -- I saw a very old TD defect about this setting item and OLE DB. It was closed with no fix/no change because of the use of STRING_NULL.
Defect title was -- I'll put in bold how to simulate this with OLE DB:
"TD OLEDB consumer, inserting/updating row via a data field or a string variable, the field in the table will contain '' (non NULL) value instead of the expected NULL for back-end like SQLserver, setting explicitly the string to STRING_Null avoids this."
Thus,
Set sVar = STRING_Null
is how to code this for OLE DB.
Re: Migrating ODBC to OLE DB
Thanks for the info Jeff.
Unfortunately the scale of changes we would need to make to retain this functionality for NULLs vs. Empty Strings make the cost-benefit impractical... so I guess we will need to continue using the ODBC router...
Regards,
Dion
Unfortunately the scale of changes we would need to make to retain this functionality for NULLs vs. Empty Strings make the cost-benefit impractical... so I guess we will need to continue using the ODBC router...
Regards,
Dion
Who is online
Users browsing this forum: [Ccbot] and 0 guests