RESOLUTION to IFX/PB4 date problems!

YESSSS!!!!! Finally after 6 weeks of debugging effort, my problem using DATE types in a client-server environment has been solved! Briefly, the problem: Running IFX SE5.02 under sunos4.1.3 & using Powerbuilder 4.0 under Windows as a front end, DATE types would be mangled. All other data would show up correctly, only dates were affected. Thinking this was a Powerbuilder problem, I contacted Powersoft tech support & began my oddysey. The most puzzling aspect was that no matter what we tried, Psoft was unable to reproduce my problem. I wont bore you with a listing of all the things we tried in our efforts to diagnose & fix the problem, suffice it to say we were *extremely* thourough! After approx. 6 weeks we were able to narrow the focus down to the date conversion routines supplied as part of the ESQL/C API shipped with Inet for Win. At this point we contacted Informix. The problem turns out to be a bug in the routines that read the informix.ini file (maintained by setnet.exe). If certain ini strings are left blank, everything works OK. If these strings have an entry, even if it is the CORRECT entry, then bad things start happening. For example my original date problem - PB4 uses date conversion routines supplied by Informix in their isqli501.dll, routines like rdatestr(), rfmtdate(), etc.. These routines use message strings stored in binary message files of suffix type .iem, usually kept in $INFORMIXDIR\\msg\\*.iem If the DBLANG string in informix.ini is left null, all works OK. But if DBLANG=c:\\informix\\msg (even though this is correct), the date routines can no longer find their format strings & they fail. PB4 obviously is not checking the return value of these functions for success or failure. Similar things happen with DBDATE. If DBDATE is left blank, then all works OK. If a value such as DBDATE=MDY2 is enterd then when doing a comparison to a date type, a string conversion error is returned by informix. I guess I'll be keeping Powerbuilder after all. Although, things happened slowly, they did provide the resources to find the cause & fix the problem. As an aside to anyone in a similar situation, I reccommend staying in close contact with the support people & bugging them constantly to keep the issue on the front burner. Although Psoft tried many things, ultimately *I* was the one to write an esql/c program that highlighted the date conversion routines as being the probable cause. Thanks for any & all suggestions from you net-folks. Every little bit helped! Mike -- Mike Stenzler 70 Hudson St. 201.798.5784 Mgr. Info. Sys. Hoboken, NJ 201.798.6367 fax RPCG, Inc. 07030 rpcg@panix.com All content my opinion only - not RPCG's.