"Mary Chipman" <mchip@nomail.please> wrote in message
news:h4ml10l1tf5sohdh42tn395kkar403eeq2@4ax.com...
> FWIW, caching the dsn/security info is a property of the TableDef and
> QueryDef objects, which you can set in the UI. The code for relinking
> tables is all over the place (www.mvps.org.access for one) and is no
> big deal. It will save you a ton of time and grief and is the
> recommended best practice. DSN's are are not recommended, but do what
> you want -- hopefully you're doing paid support at an hourly rate and
> are not being compensated to write an efficient or secure application.
>
> -- Mary
> Microsoft Access Developer's Guide to SQL Server
> http://www.amazon.com/exec/obidos/ASIN/0672319446
>
> On Thu, 29 Jan 2004 09:57:25 -0700, "JRE" <nomail@all> wrote:
>
> >Thanks Mary,
> >
> >This project was short fused and all the end users use Windows
> >authentication, so an ODBC DSN was fastest to deal with and works ok (so
> >far). For next year's application update we'll look into your suggestion.
I
> >have your developers guide and rely on it as we move more and more from
> >Access to SQL Server.
> >
> >I still think that the app not using the authentication as stored with
the
> >ODBC DSN is either a bug in Access or ODBC. I like ODBC (keeping in mind
> >it's pitfalls) because of it's ability to automatically refresh the
> >application datasets with end user changes without any coding (unlike ADO
> >datasets).
> >
> >Regards,
> >Joe
> >
> >...Good book BTW
> >
> >"Mary Chipman" <mchip@nomail.please> wrote in message
> >news:rnif10pji0lhef1bfrod2lfhhthd6csov7@4ax.com...
> >> The problem you are having involves using DSNs and is one of the
> >> really good reasons not to use them at all. They are user-specific,
> >> have to be created on each user's machine, and are intrinsically not
> >> secure. Best practice would be to create a VBA function that takes
> >> login information (such as integrated security or a SQL
> >> login/password) from a form and uses DAO code to create linked
> >> TableDef (or QueryDef) objects. When your app shuts down (also on
> >> startup), any previously linked objects are deleted. This way there is
> >> no object persistence between sessions and each user connects using
> >> their own credentials. I stress DAO here because, in some versions of
> >> Access, ADOX creates read-only linked tables.
> >>
> >> -- Mary
> >> Microsoft Access Developer's Guide to SQL Server
> >> http://www.amazon.com/exec/obidos/ASIN/0672319446
> >>
> >> On Tue, 27 Jan 2004 06:45:15 -0700, "JRE" <nomail@all> wrote:
> >>
> >> >I've done that. It's works for my SQL authentication, but then errors
out
> >> >for my co-developer with Windows authentication. Go figure...
> >> >
> >> >Thanks for the suggestion,
> >> >Joe
> >> >
> >> >"Invotion" <anonymous@discussions.microsoft.com> wrote in message
> >> >news:4b3301c3e453$a58b63a0$a401280a@phx.gbl...
> >> >> If this app uses link tables, you might try re-creating
> >> >> those links and saving the sql login / pw when you do.
> >> >>
> >> >> Sincerely,
> >> >> Invotion Engineering Team
> >> >> Advanced Microsoft Hosting Solutions
> >> >> http://www.Invotion.com
> >> >>
> >> >> >-----Original Message-----
> >> >> >I have an Access 2000 application that connects to a
> >> >> mixed mode SQL Server
> >> >> >2000 database. I connect via a SQL autentication DSN and
> >> >> a co-developer
> >> >> >connects via a Windows autentication DSN. We both
> >> >> connected fine until my
> >> >> >co-developer copied the Access application to make
> >> >> changes. Now it seems
> >> >> >that the application "assumes" a Windows ODBC
> >> >> authentication connection and
> >> >> >ignores my SQL DSN authentication when I open the
> >> >> application. I get the
> >> >> >following error message (and am prompted with a login
> >> >> message box) for each
> >> >> >table.
> >> >> >
> >> >> >The error is:
> >> >> >
> >> >> >Connection failed:
> >> >> >SQLState: '28000'
> >> >> >SQL Server Error: 18452
> >> >> >[Microsoft][ODBC SQL Server Driver][SQL Server]Login
> >> >> failed for user
> >> >> >'(null)'. Reason: Not associated with a trusted SQL
> >> >> Server connection.
> >> >> >
> >> >> >I've researched this hi and low, but to no avail, and
> >> >> have read that there
> >> >> >are "many" reasons (but few listed).
> >> >> >
> >> >> >Could anyone shed any light in this direction?
> >> >> >
> >> >> >Thanks,
> >> >> >Joe
> >> >> >
> >> >> >
> >> >> >
> >> >> >.
> >> >> >
> >> >
> >>
> >
>