[AccessD] Friday's Puzzler - Table Def "Connection"Info(Database Name)

So my advice was in the right direction, LOL.

As for posting my connection class, which one?  Most are pretty simple,
and will even be a function.

The largest one I'm almost ashamed to post, because it has changed
several times, so there is out of date code in it.  If there is a
specific process your interested in, let me know.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brad Marks
Sent: Saturday, May 29, 2010 9:07 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Friday's Puzzler - Table Def
"Connection"Info(Database Name)

Drew,

Thanks for the advice.

Just tonight, I discovered why I wasn't seeing the database name in the
table def .connect info.  

The TEST database is the default database and it is not shown in the
.connect info.
The PROD database is NOT the default database and it is shown.

In the ODBC screens to test the connection I see the same thing.

With our TEST DB, I simply see "default"
With our PROD DB, I see the actual name of the database.

I ran a bunch of tests tonight and I can tell by the data content that
the code that I use to switch between TEST and PROD is working as
expected.

Could you post your "Class"?  I would like to see how it differs from
the code that I am using.

Thanks Again,
Brad

~~~~~~~~~~~~~~~~~~~~~ 

  

-----Original Message-----
From: accessd-bounces at databaseadvisors.com on behalf of Drew Wutka
Sent: Sat 5/29/2010 6:36 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Friday's Puzzler - Table Def "Connection"
Info(Database Name)
 
Ok, going to throw my two cents in here.  First, and idea of why you
aren't getting database info with the SQL server account.

With an NT account, you have access to the entire SQL database, and you
can assign/remove permissions.  However, SQL accounts can be set to a
specific schema/database in SQL Server, so it may not be listing DB info
because it's only connecting to one database.  Not sure if that makes
sense.

The other thing I wanted to toss out there, is that typically I create a
class (used to be a plain module) for a connection object.  So instead
of having individual processes creating their connection, with their own
code, all connection goes through the same code contained within the
connection class.  There are many advantages to this.  First, just
manually switching the data source is changing one line of code.  You
can also setup dual environments, like what you are talking about, and
allow the class to handle which database it is using, and also allow any
reference to which one you are using.  Another use is keeping
connections open.  One large system I have connects to the database
quite frequently.  Instead of opening and closing the connection over
and over, in separate processes throughout the application, the class
opens the connection, and then maintains the connection for 15
seconds...if no other process needs the connection, the connection is
closed...and then reopened when it is needed.

Drew
The information contained in this transmission is intended only for the person or entity 
to which it is addressed and may contain II-VI Proprietary and/or II-VI Business 
Sensitive material. If you are not the intended recipient, please contact the sender 
immediately and destroy the material in its entirety, whether electronic or hard copy. 
You are notified that any review, retransmission, copying, disclosure, dissemination, 
or other use of, or taking of any action in reliance upon this information by persons 
or entities other than the intended recipient is prohibited.