Tcl script debate over efficiency….

[Tom Rioux]

We have an ODBC script that we use here that performs a translation on Physician ID.  There could be many instances of physicians in the message so we use arrays to assist with this functionality and getting the data back into the message.

We have ODBC functions that are being called via “namespaces”.   This ODBC call returns the data needed to place back into the message.  All of this is in one file, lets call it Physician_Logic.tcl for grins.   There are some that state it would be better if we separate the data/message manipulation portion in the “run” section from the ODBC functions in the namespaces.   They would prefer to have two separate tcl files and have the message manipulation file perform a tcl callout to the ODBC function file.

What are your thoughts on this?  (FYI, I like having it all in one file)

Thanks….

Tom Rioux

Topic

[Jim Kosloskey]

Tom,

The topic seems to indicate the debate iis over efficiency.

If that is machine efficiency, I am not sure either option would make much difference.

Also the answer will depend on the deployment of the ODBC pieces.

If the ODBC invoking code is directly related to the DBMS being referenced (meaning it has things like Table specific SQL code or names the DB in the code, etc.) then I see no advantage to externalizing the ODBC code.

On the other hand, if the ODBC code is generic in nature such that it will work with any DBMS, then I see advantages to have thie ODBC invocation code residing as a separate module. As a matter of fact that is the way I would do that.

In our case we are looking to do that kind of lookup not from Tcl code but from an Xlate. We intend to have one reusable generic ODBC module that is invoked from the Xlate. We think the module’s arguments would be provided from both a lookup Table (general connectivity, etc. arguments) as well as temp variables inside the Xlate (keys, Stored Procedure name, etc.).

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[Jeff Dinsmore]

My preference is very much like Jim’s.

My basic mantra: If it’s used in more than one place, it should be a procedure. If it’s used in more than one Tcl script, it should be in a separate Tcl file.

I use namspaces extensively to logically group related procedures. For clarity, I use one namespace to one .tcl file.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Tom Rioux]

Jim,

The code is a modified version of the one you sent me originally a while back.   In that code, you were utilizing namespaces.   We use table lookups to determine things such as server names, stored procedure code, login name/password, etc)

Your xlate solution interests me.   However, I believe you told me one time that you all connect with every message.   We have a constant connection.  We connect at start-up.  The code will shut down the thread based on certain error statuses that require user intervention.

We also have a replicated database that we connect to in the event that the primary database is down or cannot be reached for some reason.  The replicated database resides on a separate server but are kept in sync with the same data.

Question:  What if you had to perform multiple calls to the database within one message?  Would you perform a callout for connectivity, then a callout for each actaul call to the database, and then a callout for disconnect??

Thanks….Tom

[Jeff Dinsmore]

… and from an efficiency standpoint, there’s no practical performance difference from having everything in one file versus multiple files.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Jim Kosloskey]

Tom,

In our current ODBC proc (for use in a Tps) we do indeed connect and disconnect with each message. However that is because the DBAs here want it that way. No serious performance issue for Cloverleaf but has an impact for their DBMS I bet – oh well their problem not mine.

However, that is a challenge I need to attack for Xlates.

My intent is to be able to accomodate connect/disconnect with each message or connect at startup and disconnect at shutdown (or as a result of an error) and leave the connection persistent. That connectivity methodology will be argument driven for the Xltp type ODBC proc just as it is for the Tps proc currently in use.

The challenge gets greater I suspect for 5.8. I have heard the passing of globals from pre-Xlate to Xlate becomes complicated because of the multi-threading capability of Xlates in 5.8.

But first I have to get it working in 5.6.

The progress is slow because I only get time to work on this in my spare time. Here we cannot make a project of such research and development. Instead we have to wait for a project that requires the functionality – makes for some hasty development.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[Jim Kosloskey]

Tom,

As for replicated DBMS, we have the same situation here and that is handled in our connect string (the ODBC drivers allow for such specification) so that should not need to be imbedded in the code at all.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[Tom Rioux]

Jim,

Can you share your code where your talk about the replicated database being handled by the ODBC driver within your connect string?   I have written some lengthy code that checks the primary (if failed over to the replicated database).   Also, since we a persistant connection and mulitple calls within a message, we check the connection before each call to the database.   As you mentioned with yours, this was a quick fix and I would love to reduce the amount of code, if possible.

Thanks….

Tom Rioux

[Jim Kosloskey]

Tom,

The ODBC Drivers have an entry for specification of Alternate Servers.

We use Connect time strings so that is where we specify the alternate servers (that is contained in the argument Table so it is external to the Tcl code).

If you use the odbc.ini file you would make the specification there.

The Data Direct User Guide gives details on setting the alternate server attribute.

If you have any questions, email me and we can discuss off forum.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

[Tom Rioux]

If I set global variables, such as the henv or hdbc, in an inbound TPS, are those type of variables still available to me from a Tcl Callout within a translate?   Or should I move it down to the pre-route and check the “run translation procs in startup”

Thanks…..

Tom

[Author]

Replies