Here’s another tip: You may not want to use EXECUTE “!”:CMD or even a CALL or function to execute a command that you expect will take a long time. For example, you have a user waiting for Telnet or for a browser to return the results of a query that might take a couple minutes to process. You don’t want to execute the query “in-line” because the user might break into the process or close their browser, or your connectivity might simply timeout. The solution to this is to process the request asynchronously. To do this, build the sequence of operations and then pass it to a phantom or OS background task for processing. Now return control to your user. Periodically check the server to see if the query has completed. I’ll leave the mechanics of how to do that up to you. (Or you can contract with me to write this for you. 😉 ) When complete, provide the user with the information they need. This may not seem elegant to Pick people who are used to doing everything right on the spot, but this is how these things are done these days (have you heard of AJAX?). Really, the very existence of the terms Synchronous and Asynchronous should be a clue that there are techniques for solving some commonly recognized problem. Well, that’s the problem and that’s the solution. 🙂
Oh darn it! I just gave away my next great Nebula product! 😉 Seriously, now that you know how to do all of this, put your RDBMS connectivity into one or more callable subroutines, then other parts of your application can CALL to do your CRUD operations without knowing anything about the remote environment or the specific SQL being executed. Change how you do your internal operations without affecting the callers. Switch from synchronous processing to asynch as you find the need. That’s the nature of abstraction. That’s how the rest of the world does this stuff – and you can too.