VB COM, VB COM MTS Connect String Best Practice

VB COM MTS Connect String Best Practice

Author	Message
Calvin Fabr #1 / 5	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

Dennis Che #2 / 5	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

Gene Pinsk #3 / 5	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

David Hunte #4 / 5	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

Mark Howel #5 / 5	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

Page 1 of 1

[ 5 post ]