DATABASE statement in 4GLs
--------------80A826922C424D17385512CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've just been advised that use of the DATABASE statement, in 7+ engines (SE in my case) may/does cause a performance hit. I've seen no official mention of this. Reportedly, this statement causes the use of a slow runner. Is anything like this actually happening or am I being victimized by some kind of miscommunication. I use the DATABASE statement almost exclusively in a non-procedural mode, at the beginning of my globals file. Only in a few cases am I using it procedurally, when I need to build a pick list based on values in a different database. -- --------------------------------------------------------------------- Scott Holmes http://www.pacificnet.net/~sholmes sholmes@pacificnet.net Independent Programmer/Analyst Passport 4GL HTML Composer Informix 4GL, SQL --------------------------------------------------------------------- There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy --------------------------------------------------------------------- --------------80A826922C424D17385512CE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> I've just been advised that use of the DATABASE statement, in 7+ engines (SE in my case) may/does cause a performance hit. I've seen no official mention of this. Reportedly, this statement causes the use of a slow runner. Is anything like this actually happening or am I being victimized by some kind of miscommunication. I use the DATABASE statement almost exclusively in a non-procedural mode, at the beginning of my globals file. Only in a few cases am I using it procedurally, when I need to build a pick list based on values in a different database. <br> <pre> -- --------------------------------------------------------------------- Scott Holmes <A HREF="http://www.pacificnet.net/~sholmes">http://www.pacificnet.net/~sholmes</A>; sholmes@pacificnet.net Independent Programmer/Analyst Passport 4GL HTML Composer Informix 4GL, SQL --------------------------------------------------------------------- There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy ---------------------------------------------------------------------</pre> </html> --------------80A826922C424D17385512CE--
Scott Holmes wrote: First, Scott, please do not post MIME or HTML documents. Many readers are not HTML or MIME aware. This is a pure text newsgroup. Thanks. > I've just been advised that use of the DATABASE statement, in 7+ engines > (SE in my case) may/does cause a performance hit. I've seen no official > mention of this. Reportedly, this statement causes the use of a slow > runner. Is anything like this actually happening or am I being Never heard that. There is only one runner. IF you are using hte DATABASE statement to reach another database than the one mentioned in DBPATH (for SE) it is possible that you are passing every message through two sqlexec's, the local one and the remote one. Using a CONNECT statement would make a direct connection to the other database without the local server's overhead. That is the only thing I know about. > victimized by some kind of miscommunication. I use the DATABASE > statement almost exclusively in a non-procedural mode, at the beginning > of my globals file. Only in a few cases am I using it procedurally, > when I need to build a pick list based on values in a different database. Now that is a problem. When you issue a DATABASE statement it closes the current connection, which would drop your sqlexec, and begins a new connection to the other database. When you are through with the other database and issue another DATABASE statement to reconnect to the original database the whole thing happens again. There is HUGE overhead to doing this. It is probably best to access the remote lookup table through a SELECT ... FROM //dbpath/database:table. I have not used SE extensively for years but I think this should still hold. Art S. Kagel