John, You can use any UV/BASIC subroutine you like to be invoked remotely via ODBC. Some ODBC clients have various limitations on this. You can also use the IBM-supplied UCI C-API library or UniObjects or UO for Java, etc.
The main design considerations you need to be aware would include: - re-using existing code make sense, but ensure you do any initialisation sequences as well (load common - file user credentials, other settings, open file variables, etc) - your subroutine should have either input or output arguments and no input/output arguments are permitted - I find it best to 'globally' catalog a subroutine, so it can be called from any account (if this applicable for your site/functionality required - make sure it does not request any terminal input (or it will abnormally terminate) - make sure you output to a log file the results of all processing (makes debugging a lot easier) to a file for both testing and production purposes How you invoke it from your remote system/application will vary. Regards, David -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John Castilletti Sent: Tuesday, 18 August 2009 10:45 AM To: U2 Users List Subject: Re: [U2] Connecting to a Universe Database David, Do you have examples for the use of UV/BASIC subroutines invoked as stored procedures from SQL Server/ Thanks, John ________________________________ From: "Hona, David" <[email protected]> To: U2 Users List <[email protected]> Sent: Monday, August 17, 2009 7:20:03 PM Subject: Re: [U2] Connecting to a Universe Database It is highly recommended that you upgrade your version of UniVerse before you consider what interface to use. An ODBC interface is mostly the easiest to implemented, but the slowest and hardest to debug. Especially on such an old version of UniVerse. Further, unless you're UV data is in a format readily or easily translatable/accessible from SQL Server - then you'll be forced to use intermediary tables to "bridge" the updates. Imagine the worst-case scenario where your live UV database is irreversibly corrupted by erroneous SQL Server UPDATE statement(s). A potential work-around would be the use of UV/BASIC subroutine(s) invoked as a stored procedure from SQL Server to translate the underlying complexities of your UV database/application. Hence, helping to manage this risk of corruption (to an extent) and also potentially negating the need for multiple and complex SQL queries and update statements (potentially aiding performance). You don't mention the nature of the processing model. So you'll also need to also carefully consider the potential database lock contention issues and the impact of updates (esp. bulk updates) or queries on the performance of your UV system...should have a system that is already heavily utilised or has performance or reliability issues. Regards, David ************** IMPORTANT MESSAGE ***************************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ************************************************************** _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
