VB COM MTS Connect String Best Practice 
Author Message
 VB COM MTS Connect String Best Practice

Hi,

We are implementing database-intensive VB COM objects under MTS that will
hit SQL Server 7.0  When these objects are instantiated, where is the best
place to get the connect string from?

1.  System DSN with password in registry?
2.  Hard-coded connect string in object (as in FMStocks)
3.  Sent from calling application as parameter?
4.  Separate application-specific registry entry

Thanks,

Calvin Fabre



Fri, 05 Jul 2002 03:00:00 GMT  
 VB COM MTS Connect String Best Practice
An INI or XML file. COM objects can have problem to access the registry.


Quote:
> Hi,

> We are implementing database-intensive VB COM objects under MTS that will
> hit SQL Server 7.0  When these objects are instantiated, where is the best
> place to get the connect string from?

> 1.  System DSN with password in registry?
> 2.  Hard-coded connect string in object (as in FMStocks)
> 3.  Sent from calling application as parameter?
> 4.  Separate application-specific registry entry

> Thanks,

> Calvin Fabre




Fri, 05 Jul 2002 03:00:00 GMT  
 VB COM MTS Connect String Best Practice
If your connection string remains the same for different connections (that
you would typically do to enable connection pooling), the best temporary
storage in terms of performance would be Shared Property with SPM under MTS.
Well, hardcoded would be even faster, but in this case you will have to
rebuild your COM object every time you will need to make any changes.
Gene


Quote:
> Hi,

> We are implementing database-intensive VB COM objects under MTS that will
> hit SQL Server 7.0  When these objects are instantiated, where is the best
> place to get the connect string from?

> 1.  System DSN with password in registry?
> 2.  Hard-coded connect string in object (as in FMStocks)
> 3.  Sent from calling application as parameter?
> 4.  Separate application-specific registry entry

> Thanks,

> Calvin Fabre




Sat, 06 Jul 2002 03:00:00 GMT  
 VB COM MTS Connect String Best Practice
I have never had a problem getting COM objects to read from the registry.
As long as you're designing things properly, and storing your information in
HKEY_LOCAL_MACHINE instead of somewhere silly like HKEY_CURRENT_USER, you're
fine.

This is what I usually do for my connection strings.  It means that any
component which needs to access a particular database can be sure of using
the same connection string, and I find getting the information out of the
registry to be pretty quick.  (Not measurably slower than hard-coding,
although obviously it is.)  I find it can also be easier to set up than
creating a System DSN.

--
David Hunter
MobileQ
http://www.MobileQ.com


Quote:
> An INI or XML file. COM objects can have problem to access the registry.



> > Hi,

> > We are implementing database-intensive VB COM objects under MTS that
will
> > hit SQL Server 7.0  When these objects are instantiated, where is the
best
> > place to get the connect string from?

> > 1.  System DSN with password in registry?
> > 2.  Hard-coded connect string in object (as in FMStocks)
> > 3.  Sent from calling application as parameter?
> > 4.  Separate application-specific registry entry

> > Thanks,

> > Calvin Fabre




Mon, 08 Jul 2002 03:00:00 GMT  
 VB COM MTS Connect String Best Practice
I would highly recommend passing the Connect String as a parameter to the
method returning the recordset.  The reason is that if you need to support
multiple databases (for example, Production, Test, Development...) then you
need to be able to change the target db from a login screen on your
application.   Connect strings are relatively short so the overhead is small
for the flexability gained.  Also, pay attention to subsequent emails
regarding INI files and Registry access.  If you are running in a clustered
environment, you will NOT want to do Registry access (or really INI either
for that matter) unless you want to pull all of your hair out.

You also cannot create an object in MTS, set the connect string, then use it
later.  Remember that MTS handles all pooling and sharing of objects.

HTH.
--
Mark Howell
dBToolWorks


Quote:
> Hi,

> We are implementing database-intensive VB COM objects under MTS that will
> hit SQL Server 7.0  When these objects are instantiated, where is the best
> place to get the connect string from?

> 1.  System DSN with password in registry?
> 2.  Hard-coded connect string in object (as in FMStocks)
> 3.  Sent from calling application as parameter?
> 4.  Separate application-specific registry entry

> Thanks,

> Calvin Fabre




Sat, 10 Aug 2002 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. VB COM ADO MTS Connect String Best Practice

2. Best partition practice for MTS package

3. Urgent:: Use of COM/COM+ and XML data to interface Oracle DB, best practices

4. Variants vs. Types in COM objects...best practices

5. QUESTION: Error Handling and COM obj's - best practices

6. Dataview to string best practice

7. newbie - COM with MTS Vs COM without MTS

8. VB.NET Good GUI Framewerk Practices

9. VB.Net Best Practice - Recommedation?

10. Best Practice in VB .NET

11. CREATING wizards in vb: best programming practice?

12. good programming practice!!?? and VB controls

 

 
Powered by phpBB® Forum Software