I think someone posted the name of the voc entry required if you want to do something at the time of an ODBC login, such as initializing named common memory. Otherwise, I suspect it is in the doc somewhere (sorry I don't have more details). Check the voc on your previous system for an entry like ...ODBC... and on the new and be sure the same routine is present, compiled, cataloged on both machines. --dawn
Dawn M. Wolthuis Tincat Group, Inc. www.tincat-group.com Take and give some delight today. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Wallis Sent: Wednesday, April 21, 2004 4:51 AM To: 'U2 Users Discussion List' Subject: [UD] Known ODBC Linux or 6.0 issues? Sorry to have to throw this out without fully researching it first, but I've got a client with a pressing problem. They are in the final stages of preparing to switch over from their current DG-UX Intel platform running UniData 5.2 to a new Linux based system running 6.0 and ODBC doesn't appear to be working correctly when they access virtual fields that call SUBRoutines. There is one critical process that requires ODBC to be up and running and this makes use of a number of SUBR virtual fields. Needless to say, everything works fine against the DG. The new system is RH 2.1 ES (kernel build 2.4.9-e34smp) running UniData 6.0.5. Is anyone aware of any known issues with ODBC on this platform, or of any gotchas they may have forgotten to set up properly regarding calling SUBRs via dictionary fields accessed through ODBC. The queries apparently run fine if cut and pasted in at the "sql>" prompt (other than a few warnings about missing associations), but blow up with a variety of errors (fetch errors, 81002 and 81001s) when run through MS Query. Ramping the logging level at the server up to 9 seems to show the server log just stopping in mid flow at about the time that the queries blow up and die. Queries which only access data fields run OK, but if they call a SUBR it gets nasty. I'm at a bit of a loss on this one and working only on info gained from a long telephone call at present so I'm afraid the details are sketchy. I'm hoping someone in a different timezone has seen this before and solved it (or knows it can't be solved) so we can short-circuit things a bit tomorrow as I try to track down and resolve this before cutover on the weekend! Cheers, Ken -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
