Results 1 to 5 of 5
  1. #1
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713

    Unanswered: FYI - DSNs and their differences and uses ...

    Check this link out. VERY good explanation of DSNs...

    http://support.microsoft.com/default...b;EN-US;193332
    Back to Access ... ADO is not the way to go for speed ...

  2. #2
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    i gave up on DSNs - had enormous problems getting non-tekkie people running with them. i never did understand why some folk couldn't connect with my DSNs, but all the problems went away with DSN-less connections.

    frankly, i can't see what a DSN brings to the party even if it does work for everyone. what am i missing? are there any reasons to prefer a DSN ??

    izy
    currently using SS 2008R2

  3. #3
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713
    Quote Originally Posted by izyrider
    i gave up on DSNs - had enormous problems getting non-tekkie people running with them. i never did understand why some folk couldn't connect with my DSNs, but all the problems went away with DSN-less connections.

    frankly, i can't see what a DSN brings to the party even if it does work for everyone. what am i missing? are there any reasons to prefer a DSN ??

    izy
    Izy,

    I've never had a problem with them ... The thing I love about them best is that you can use a DSN and not have to worry about a hardcoded path (or db name) to connect to - or even a "semi" hardcoded path or name ... Where the file resides or what it's name is is transparent to the application connection to the database ...
    Back to Access ... ADO is not the way to go for speed ...

  4. #4
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    fair point!

    i use a hard-coded global constant as connection string, so a switch to a new backend is only a couple of characters of typing.

    i do admit that very occasionally i use a saved query to attack a remote db so a DSN would save the hassle of copy/pasting the connection string into a few passthru queries, but then again i'd have to switch the DSN in those queries anyway since new backend almost certainly means new frontend to handle new backend features.

    i know globals vaporise in a crash, but then again my code is designed not to crash! in any case, if i loose my global connection string i've lost all my other globals, so it's a great time for the frontend not to be able to talk to the data at all.

    i just wondered if it was somehow faster to use a DSN or something?

    izy
    currently using SS 2008R2

  5. #5
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713
    Quote Originally Posted by izyrider
    i just wondered if it was somehow faster to use a DSN or something?

    izy
    Not really ... That is determined by the object you use to connect with ... The screamer I used in the past was an ADO object in the msado15.dll (using c++). Talk about instant update!!
    Back to Access ... ADO is not the way to go for speed ...

Posting Permissions

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