Jason,
I have just started doing ODBC with Cloverleaf(R) and I have decided not to use the odbc.ini file for every DB.
Instead I use a Connection String wherein I reference a DB Type’s (let’s say Oracle) provided dsn in the odbc.ini file.
Then I enter in the connection string those entries that differ from the distributed dsn.
This gives me a stable odbc.ini file and the flexibility of connect time definition of the connection, etc. characteristics.
I use a lookup table to contain the connection string entries as well as other arguments I need for my proc but the arguments could just as wellbe in the NetConfig.
Using the connection string method does not preclude the use of the odbc.ini file so if it is necessary to have specific definitions in the odbc.ini that can be done. This seems to give me the most flexibility.
My goal is to have a reusable ODBC proc that is argument driven.
To that end we are attempting to only deal with Stored Procedures. That way the ‘business rules’ are separated from Cloverleaf(R) and exist with the receiving system and the Cloverleaf(R) proc can be ignorant of the specifics of the business or data management functions.
Also, ideally the Stored Procedure with which we will interact actually inserts in a transaction table. Later another mechanism of the receiving system’s choice picks up the transaction and processes it.
This way Cloverleaf(R) delivers a message and upon successful completion of a very simplistic Stored Procedure, can move on to the next message.
The receiving system then has a natural ‘queue and audit trail’ of received messages. They can archive, analyze and otherwise manage those received messages as they see fit. Moreover, an opportunity arises to completely trace and debug the message flow.
Anyway, that is the plan. Many of the above pieces are in place or are being actively tested.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.