So far as I'm aware, applications compiled in Team Developer 5.X require specific versions of the SQLWNTM.DLL and SQLAPW.DLL libraries (noted as 10.0.x in the TD5.1 deploy, 5.1.x in the TD5.2 deploy) in order to run. Using a "DLL Reader", I can see theTD-centric versions of SQLWNTM.DLL contain both ANSI and Unicode functions, and one in particular -- export ordinal 247 (sqlgetW) -- appears to be an absolute must for database connectivity.
Problem is, the various SQLBase deployments (at least up to 11.5) come with their own versions of SQLWNTM.DLL and these do not include the unicode functions -- in fact there are less than 161 exposed functions... If Team Developer encounters these libraries, it returns an "ordinal 247 not found" error, and rightfully so as it doesn't exist. The tentative workaround for us once we moved to TD5.1 was then to leave the native sqlbase components (most of our clients are actually still on 8.5) in the SQLBase home directory, and include the TD-centric versions of SQLWNTM.DLL and SQLWS32.DLL in the compiled application's runtime directory, and hope that despite the mismatched components, everything would sort itself out. Though I had seen 7.5.1 client comnponents bring about much instability when connecting to an 8.5 backend, I was assured it shouldn't be an issue, and for the most part I'd agree it functions well...
...Until we upgraded one of our network clients to a SQLBase 11.5 Treasury Edition backend. Here the prospect of using multiple DLL's in their respective application directories breaks down -- the TD-Centric SQLWNTM.DLL library apparently doesn't support the encryption functionality -- it throws an error if the SECUREAPI keyword it located within the SQL.INI's [win32client] key... The only solution I could come up with: comment out the keyword and disable transmission security on the client, compromising security.
SQLBase <---> SQLWindows should be a seamless integration, that's why we use the products... To be more specific about our challenge as a software developer... Our annual software releases serve as a historical archive of tax data -- so our clients maintain and use software going back into the 90's, and we have to make it all work together in an easy to manage client-server environment... We have alot of folks on a SQLBase 8.5 backend, which has worked well to support all our 32bit applications from 2000-2008. Those 2000-2008 applications were created in various incarnations of TD2.x, TD3.x, etc, and it always played nicely with any version of SQLBase... Until 2009 when we go to TD5.X, and now suddenly the TD SQLWNTM library seems to forgo any sort of compatibility with even current sqlbase products, which use the same library and same naming convention? Am I missing something, or drastically mucking up our deploy schemes? I just don't get it... help