RE: [UD] Known ODBC Linux or 6.0 issues?
Dawn M. Wolthuis wrote: 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 The entire account got moved across, VOC and all and then convcode/convdata-ed. So I don't think we can be missing any VOC entries, but I cannot find any sign of a paragraph which fits the description. I've also searched the PDF doco and the list archives but can't find anything which says what the name of the paragraph/cataloged routine needs to be in order to do one-time initialisation for ODBC sessions like LOGIN does for udt sessions. I do notice that if I go to the account directory and go straight into sql (no LOGIN paragraph run) the query fails abruptly with a message about an unopened file variable and a MATREAD error, but if I go first into udt (LOGIN initialisation runs) and then from there to sql then the query is fine. Can anybody definitively say what I need to have (VOC entry or cataloged routine) and what it needs to be called in order to get initialisation done when an ODBC session is connected? Cheers, Ken -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UD] Known ODBC Linux or 6.0 issues?
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
RE: [UD] Known ODBC Linux or 6.0 issues?
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
Re: [UD] Known ODBC Linux or 6.0 issues?
Ken, At the risk of stating the obvious, have you checked that the correct version of the SUBR is cataloged? 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. Ken - Sincerely, Charles Barouch www.KeyAlly.com [EMAIL PROTECTED] -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UD] Known ODBC Linux or 6.0 issues?
Wol wrote: 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. OK, further info: It appears that under 5.2 on the DG box, it is OK for the SUBRoutines being called to be locally cataloged, but under 6.0 on Linux, it only works via ODBC if the routines are globally cataloged! Unfortunately there are a number of these subroutines and they aren't necessarily the same in all accounts, so globally cataloging everything isn't the nicest option... Cheers, Ken -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
