Drew Wutka
DWUTKA at marlow.com
Wed Mar 12 16:07:01 CST 2003
Actually, of all the 'big' debates I have seen on the list, the Global one is pretty lame. Most of the debates get into heated discussions over the fine tunings of an application, or the database engine, or even picky details of theory. The Global issue is really centered around a myth. The myth is that they are unstable. This is entirely untrue. A global variable holds a value for the life of your session. Now, in VB, when you have an .exe, or you run a project in debug mode, when you hit 'end', or stop your code, your entire project stops, so you expect your globals to disappear. However, in Access, stopping your code doesn't close forms, or shut anything down, it just stops the running code. The Globals are 'lost', but that is because your code has stopped running. Since the database still looks intact, Globals have gotten the impression that they are 'flaky'. Do you see what I am saying? Drew -----Original Message----- From: Marcus, Scott (GEAE, RHI Consulting) [mailto:scott.marcus at ae.ge.com] Sent: Wednesday, March 12, 2003 12:46 PM To: 'accessd at databaseadvisors.com' Subject: RE: [AccessD] Using Global Connctions Drew, I miss the debate we had last time on globals. Fortunately I'm not Borg so resistance is not futile. I wonder if JC is paying attention. Scott -----Original Message----- From: Drew Wutka [mailto:DWUTKA at marlow.com] Sent: Wednesday, March 12, 2003 1:31 PM To: 'accessd at databaseadvisors.com' Subject: RE: [AccessD] Using Global Connctions Love Globals. They are just as reliable as any other code. If someone did, it would be me! <VBG> Sometimes. Yes, all the time. I 'hit and release' my ADO Connections all the time, especially when on a LAN. In fact, the first vergence from that practice just happened last night. I am working on a web interface to a Contact Request database. The database is on our Internet Web Server, and the Web interface is on our Intranet Web Server. Creating the connection through the network (from server to server) takes about half a second to a second (didn't really time it...). I have multiple classes working on each page, each of which require db interaction. Opening and killing the connection creates unacceptable delays (3 to 4 seconds per page load...I know that's not too bad, but in comparison to almost instantaneous pulls with the method I am using now, there is a big difference). So what I did, was take a major 'class', which represents information about the person logged in (it's used in every page), and I load an instance of that class, if it hasn't been loaded. If it has been loaded, I pull the class from a Session variable, which has already been loaded. That class keeps the connection open while the class is live, so I can then pass the connection object to other classes, keeping it open the entire time. With that method, the first page on the site (whatever page is hit) takes a few moments to load, but from that point on, the site runs as fast as the user can click. I left the default timeout of 10 minutes on the session object, so as long as the user doesn't wait more then 10 minutes before doing something on the site, they won't experience the temporarily delay in the main class loading. Drew -----Original Message----- From: Mark L. Breen [mailto:subs at solution-providers.ie] Sent: Wednesday, March 12, 2003 3:35 AM To: accessd at databaseadvisors.com Subject: [AccessD] Using Global Connctions Hello All, As a follow up to Susan Harkins discussion on the command object, How do you guys use a global connection in your apps What I have been doing is initialising gccnn when I load the app. It is G lobal C onstant cnn. I then use this Global variable for every ADO section of code. Do you hate global variables? do you think that they are unreliable? do you think that someone is going to come in the middle of the night and wipe it out? Do you use a class or property pass it around instead? In a fat client, LAN, does anyone initialise it and close it each time? (I presume not) Just intested in your feedback Thanks _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com