Hi everyone

We've written our own ADO routines which use a .NET library, and this is working quite well.

I'm now looking to utilise these same routines for our existing ODBC functionality by overwriting the relevant routines e.g. XOInstance, QryMethod, XOGetProperty etc, as the ODBC driver we use is very old and heavy and not completely stable.

Our inheritance account chain is currently SYSPROG ← ORYX ← customAccounts

I tried copying my custom XOInstance routine (ado_xoinstance) into the ORYX account (SYSOBJ → $XOINSTANCE*ORYX) however it still links to the SYSPROG version when I recompile another proc also within OrYx (or other inherited routines) and reference the xoinstance function.

Do I actually have to overwrite the $XOINSTANCE record in SYSPROG itself? I was hoping not to have to do this for obvious reasons.

Hi everyone

We've written our own ADO routines which use a .NET library, and this is working quite well.

I'm now looking to utilise these same routines for our existing ODBC functionality by overwriting the relevant routines e.g. XOInstance, QryMethod, XOGetProperty etc, as the ODBC driver we use is very old and heavy and not completely stable.

Our inheritance account chain is currently SYSPROG ← ORYX ← customAccounts

I tried copying my custom XOInstance routine (ado_xoinstance) into the ORYX account (SYSOBJ → $XOINSTANCE*ORYX) however it still links to the SYSPROG version when I recompile another proc also within OrYx (or other inherited routines) and reference the xoinstance function.

Do I actually have to overwrite the $XOINSTANCE record in SYSPROG itself? I was hoping not to have to do this for obvious reasons.

The direct answer to your subject question is "yes". However, as you noted, this isn't what you want to do.

After you created your $XOINSTANCE*ORYX, did you restart OI? I'm wondering if you already had $XOINSTANCE loaded into memory. You could also force OI to reload by bringing up the System Monitor and enter:

RUN RTP27 "XOINSTANCE"

Then test again.

Don Bakke

SRP Computer Solutions, Inc.

Hi Don

Thanks for the quick reply. I did restart OI.

The SYSOBJ record I copied was from my new "ADO" account ie. $ado_xoinstance*ADO to $xoinstance*ORYX I

I thought that just copying the record like this would be enough so get the ORYX version when I compiled in any non-SYSPROG account in ORYX or below. But it doesn't seem to be.

I tried the RUN RTP27 'XOINSTANCE' too, which did appear to reload in that in sysmon it said:

RUN RTP27 'XOINSTANCE'

XOINSTANCE,

.

But it still pointed to the SYSPROG one. It definitely works when I overwrite the SYSPROG version, but this is obviously not a great idea, if I can avoid it.

Hi Don

Thanks for the quick reply. I did restart OI.

The SYSOBJ record I copied was from my new "ADO" account ie. $ado_xoinstance*ADO to $xoinstance*ORYX I

I thought that just copying the record like this would be enough so get the ORYX version when I compiled in any non-SYSPROG account in ORYX or below. But it doesn't seem to be.

I tried the RUN RTP27 'XOINSTANCE' too, which did appear to reload in that in sysmon it said:

RUN RTP27 'XOINSTANCE'

XOINSTANCE,

.

But it still pointed to the SYSPROG one. It definitely works when I overwrite the SYSPROG version, but this is obviously not a great idea, if I can avoid it.

James - Can you confirm that your SYSOBJ key is in all caps (i.e., $XOINSTANCE*ORYX)? I just want to make sure that was simply a typo in your last post. Otherwise, that would be highly relevant.

Don Bakke

SRP Computer Solutions, Inc.

Hi Don

Yep a typo - they keys are all CAPS

James,

You probably need to remove the name from the SYSPROCNAMES record.

Take a look here for more info on the loading process:

http://sprezzblog.blogspot.com/2009/05/sysprocnames-explained.html?m=1

Carl Pates

James,

You probably need to remove the name from the SYSPROCNAMES record.

Take a look here for more info on the loading process:

http://sprezzblog.blogspot.com/2009/05/sysprocnames-explained.html?m=1

Carl Pates

I was just about to point this out. I knew that removing (or simply placing an asterisk in front of the name) and restarting OI was necessary to compile a stored procedure with the same name, but I didn't realize it was necessary in order to call object code of the same name in an inherited application. I had just finished testing this theory when this response came in. So, James, I concur with Carl that you should update the SYSPROCSNAMES record and this should get you squared away.

Don Bakke

SRP Computer Solutions, Inc.

Hi Carl and Don

Perfect! Removing this line from within SYSENV → SYSPROCNAMES, restarted OI and all is good in the world again! Thanks! I'll update my routine to do this automatically.

Am I right in assuming that SYSENV will be re-written with all the XO* and QRY* routines during certain updates?

Thanks again for the speedy resolution, I really appreciate it.

Yep - Always assume you need to check SYSPROCNAMES after an OI update if you’ve modified it.

Carl Pates

No worries.

Thanks Carl

Or you could follow the guidance in this blog post and either use an application specific MD or a virtual MD, thus ensuring that upgrades don't overwrite anything.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

View this thread on the Works forum...