You'll need to search the archives for this (I don't have any of the stuff you mention :-) but there was discussion about calling virtual fields from ODBC a little while ago.
I think at least one of the points was "does it rely on environment variables or stuff set up by LOGIN?" It appears that ODBC has a different login setup to a normal user - maybe even that UD needs a correct $PATH to find the executable for SUBR? I dunno. Or do the SUBRoutines rely on an initialised COMMON? I think it should work (that was the consensus of the previous thread iirc) but tracking down the exact problem might be a pain. Cheers, Wol -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Wallis Sent: 21 April 2004 10:51 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 **************************************************************************** This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333. **************************************************************************** -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
