Changing DSN without ReCompile

Results 1 to 6 of 6

Thread: Changing DSN without ReCompile

  1. #1
    Craig Adams Guest

    Default Changing DSN without ReCompile

    I have a COM object that connects to a database and issues SQL commands. I have hard-code the connect string (Public Const vDSDBConn As Variant = "Provider=SQLOLEDB.1;User ID=***;Initial Catalog=ams_diamondsource;Data Source=CADAMS-4150"). My question is when I use this object with different SQL servers, I have to change the above code and recompile. There has to be a better way. Can anyone provide suggestions?<BR>Thanks

  2. #2
    SPG Guest

    Default Why ever did you hard code it?

    Just seems like bad practice to me; it&#039d be much better to have<BR><BR>public property let strConn(byVal strIn as string)<BR> vDSDBConn = strIn<BR>end property<BR><BR>public property get strConn() as string<BR> strConn = vDSDBConn<BR>end property<BR><BR>&#039Set the default value because we&#039ll be lazy<BR>&#039 on our own server...<BR>private sub Class_Initalize()<BR> strConn = "Provider=SQLOLEDB.1;User ID=***;Initial Catalog=ams_diamondsource;Data Source=CADAMS-4150"<BR>end sub

  3. #3
    Join Date
    Dec 1969

    Default RE: Why ever did you hard code it?

    U could also use the windows registry which is ideal for such purposes. Use SaveSetting to make an entry and GetSetting to retrive the values. this way no need of recompilation. all u got to do when connecting to a diff sql server is change the registry setting

  4. #4
    SPG Guest

    Default But the Registry is Slow...

    ... which is why DSN connections aren&#039t as popular as they used to be. Instead of simply passing a value into a component for every use, the component would have to go look up the value in the windows registry for every use, thus involving another part of the system which hitherto didn&#039t care. <BR><BR>(And every part of the system that cares about a component makes it move a bit slower and makes it more difficult to maintain.)<BR><BR>It&#039s an worthwhile solution, but, on face, I wouldn&#039t use it for this problem.

  5. #5
    Join Date
    Dec 1969

    Default RE: But the Registry is Slow...

    You could of course just use a regular INI-file, that saves the overhead caused by the registry and is far more portable.<BR><BR>Plus, INI-files are really fast (but make sure that you use the Kernel-functions to access INI-files, don&#039t write your own). It&#039s my experience that reading even dozens of keys is still lots faster than reading the entire file into an array and dissect it key by key. Just use the raw power

  6. #6
    Mike Samra Guest

    Default RE: But the Registry is Slow...

    I agree with either using the Registry or the INI file, both have worked fine.<BR><BR>I usually read from these locations and then store it in the MTS Shared Property Manager for retrieval after that..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts