Prev: Calculating comboboxes
Next: How to find the name of the present subform
From: Sylvain Lafontaine on 8 Apr 2010 14:09
Well, I would say that if your previous posts were clear, you would have
received a clear answer from me or from someone else around here. A
question well stated is a question half solved.

You have made a mention about beeing obligated to make an extra step to make
it work on a 64 bit OS. However, you don't say what exactly is this extra
step and you didn't post an example of a working connection string; so it's
nearly impossible for us to make any call on this. BTW, when we speak about
posting a connection string, we really don't care about seeing the username
and the password and you can safely remove them before posting the rest (but
without forgetting to mention if you are using the Integrated Security of
Windows or a SQL-Server authentication login).

Finally, don't forget that you are the only one in front of your machine,
knowing what things you have installed on it and capable to perform some
basic tests on it.

--
Sylvain Lafontaine, ing.
MVP - Windows Live Platform
Blog/web site: http://coding-paparazzi.sylvainlafontaine.com
Independent consultant and remote programming for Access and SQL-Server
(French)


"mat" <mat(a)notarealdotcom.adr> wrote in message
news:MPG.2627a46f182453dd9897c2(a)msnews.microsoft.com...
> In article <#Y8j$xb1KHA.2028(a)TK2MSFTNGP05.phx.gbl>,
> sylvainlafontaine2009(a)yahoo.ca says...
>> The general impression from your first post was that you were unable to
>> connect from an Access installation running on a 64 bit OS. Now, it
>> looks
>> that you are able to connect but that you question is about some "extra
>> step".
>>
>> What's exactly this extra step that you are talking about and what are
>> the
>> connection strings that you are actually using on the 32 bit OS and on
>> the
>> 64 bit OS?
>>
>
> It's not really a complicated question and I've outlined the issue many
> times in this thread, including in my prev response to you. The actual
> connection string I am not going to post on a public forum, complete
> with password etc, but the original post contains a munged, completely
> ordinary connections string that works on 32 bit. The 64 bit conn string
> is the same; and fails. That's the question, why does it fail?


From: mat on 8 Apr 2010 18:33
In article <e#FEsa01KHA.4908(a)TK2MSFTNGP04.phx.gbl>,
sylvainlafontaine2009(a)yahoo.ca says...
>
> Well, I would say that if your previous posts were clear, you would have
> received a clear answer from me or from someone else around here. A
> question well stated is a question half solved.
>
> You have made a mention about beeing obligated to make an extra step to make
> it work on a 64 bit OS. However, you don't say what exactly is this extra
> step and you didn't post an example of a working connection string; so it's
> nearly impossible for us to make any call on this. BTW, when we speak about
> posting a connection string, we really don't care about seeing the username
> and the password and you can safely remove them before posting the rest (but
> without forgetting to mention if you are using the Integrated Security of
> Windows or a SQL-Server authentication login).
>
> Finally, don't forget that you are the only one in front of your machine,
> knowing what things you have installed on it and capable to perform some
> basic tests on it.

The extra step needed to get a dsn-less connection working on a 64 bit
OS is what I am looking for, if there is such a thing. No one has
responded to my many requests for input on that. Does the same
connection string work for anyone else on both 32 and 64 bit os? I've
asked that many times here. The extra config options that one must got
through on a 64 bit OS when setting up a dsn is well known to me, as
I've written. The question is, is there anything parallel to that with a
dsn-less connection.

Honestly I've gotten a ton of help from this ng over the years. The
question I've posed here is pretty simple, and shouldn't be esoteric.
Yet I've gotten zilch input. I'm not interested in sparring with you
over whether I've posted a question that is up to your standards. If you
can't understand what I'm asking about after all of this communication,
or simply don't know the answer, then please don't worry about it.

I even asked Mary Chipman about it and she does not seem to know either.
64 bit os are mainstream now, so I don't get why this is such a tough
question.

Simply if someone could tell me that they know from direct experience
that there is or isn't any need for a connection string to sql server
2005 express to be different between a 32 bit and 64 bit os, then at
least I'd know if I was barking up the right tree or not.
From: Sylvain Lafontaine on 8 Apr 2010 20:56
Even on a 64 bit OS, Access is running under the 32 bit emulation mode
because it's a 32 bit application and therefore, the same connection string
should always work for both 32 and 64 bit OS to connect to an instance of
SQL-Server from Access.

Furthermore, if I remember correctly, the Express edition of SQL-Server 2005
can only be installed under the 32 bit mode; contrary to the Express edition
of SQL-Server 2008 which can be installed to run natively under the 64 bit
mode.

Second, you should check the protocol that you are using. With SQL-Server,
three different protocols can be used: the Shared Memory protocol, the Named
Pipe protocol or TCP/IP. Maybe you have a configuration problem at this
level. For example, if TCP/IP is set to be the default protocol to be used
but that it has been inactivated in the configuraton of the SQL-Server, then
you won't be able to connect. You should check your configuration to see
what protocols have been activated.

Finally, when you have a connection problem, you should tell us what your
exact situation. For example, if you can connect using a DSN connection,
then you should told us as this can eliminate some possibilities. Same
thing if you can connect using another program such as SQL Server Management
Studio (SSMS) or if you can connect or not from another machine. Make sure
also that the SQL-Server Service is running properly. If it has not be
started, you won't be able to connect to it from Access. While checking the
service, take the time to verify that its name is SQLExpress and not
something else and an unnamed instance.

--
Sylvain Lafontaine, ing.
MVP - Windows Live Platform
Blog/web site: http://coding-paparazzi.sylvainlafontaine.com
Independent consultant and remote programming for Access and SQL-Server
(French)


"mat" <mat(a)notarealdotcom.adr> wrote in message
news:MPG.2627f98ecc986f029897c3(a)msnews.microsoft.com...
> In article <e#FEsa01KHA.4908(a)TK2MSFTNGP04.phx.gbl>,
> sylvainlafontaine2009(a)yahoo.ca says...
>>
>> Well, I would say that if your previous posts were clear, you would have
>> received a clear answer from me or from someone else around here. A
>> question well stated is a question half solved.
>>
>> You have made a mention about beeing obligated to make an extra step to
>> make
>> it work on a 64 bit OS. However, you don't say what exactly is this
>> extra
>> step and you didn't post an example of a working connection string; so
>> it's
>> nearly impossible for us to make any call on this. BTW, when we speak
>> about
>> posting a connection string, we really don't care about seeing the
>> username
>> and the password and you can safely remove them before posting the rest
>> (but
>> without forgetting to mention if you are using the Integrated Security of
>> Windows or a SQL-Server authentication login).
>>
>> Finally, don't forget that you are the only one in front of your machine,
>> knowing what things you have installed on it and capable to perform some
>> basic tests on it.
>
> The extra step needed to get a dsn-less connection working on a 64 bit
> OS is what I am looking for, if there is such a thing. No one has
> responded to my many requests for input on that. Does the same
> connection string work for anyone else on both 32 and 64 bit os? I've
> asked that many times here. The extra config options that one must got
> through on a 64 bit OS when setting up a dsn is well known to me, as
> I've written. The question is, is there anything parallel to that with a
> dsn-less connection.
>
> Honestly I've gotten a ton of help from this ng over the years. The
> question I've posed here is pretty simple, and shouldn't be esoteric.
> Yet I've gotten zilch input. I'm not interested in sparring with you
> over whether I've posted a question that is up to your standards. If you
> can't understand what I'm asking about after all of this communication,
> or simply don't know the answer, then please don't worry about it.
>
> I even asked Mary Chipman about it and she does not seem to know either.
> 64 bit os are mainstream now, so I don't get why this is such a tough
> question.
>
> Simply if someone could tell me that they know from direct experience
> that there is or isn't any need for a connection string to sql server
> 2005 express to be different between a 32 bit and 64 bit os, then at
> least I'd know if I was barking up the right tree or not.


From: mat on 9 Apr 2010 01:18
In article <#VX2G#31KHA.224(a)TK2MSFTNGP06.phx.gbl>, sylvainlafontaine2009
@yahoo.ca says...
>
> Even on a 64 bit OS, Access is running under the 32 bit emulation mode
> because it's a 32 bit application and therefore, the same connection string
> should always work for both 32 and 64 bit OS to connect to an instance of
> SQL-Server from Access.
>
> Furthermore, if I remember correctly, the Express edition of SQL-Server 2005
> can only be installed under the 32 bit mode; contrary to the Express edition
> of SQL-Server 2008 which can be installed to run natively under the 64 bit
> mode.
>
> Second, you should check the protocol that you are using. With SQL-Server,
> three different protocols can be used: the Shared Memory protocol, the Named
> Pipe protocol or TCP/IP. Maybe you have a configuration problem at this
> level. For example, if TCP/IP is set to be the default protocol to be used
> but that it has been inactivated in the configuraton of the SQL-Server, then
> you won't be able to connect. You should check your configuration to see
> what protocols have been activated.
>
> Finally, when you have a connection problem, you should tell us what your
> exact situation. For example, if you can connect using a DSN connection,
> then you should told us as this can eliminate some possibilities. Same
> thing if you can connect using another program such as SQL Server Management
> Studio (SSMS) or if you can connect or not from another machine. Make sure
> also that the SQL-Server Service is running properly. If it has not be
> started, you won't be able to connect to it from Access. While checking the
> service, take the time to verify that its name is SQLExpress and not
> something else and an unnamed instance.

Yes the server is started; dsn connections work fine as I noted many
times. tcp/ip. Names in the string are good.
From: Sylvain Lafontaine on 9 Apr 2010 11:44
"mat" <mat(a)notarealdotcom.adr> wrote in message
news:MPG.2628589ef1b974919897c4(a)msnews.microsoft.com...
> In article <#VX2G#31KHA.224(a)TK2MSFTNGP06.phx.gbl>, sylvainlafontaine2009
> @yahoo.ca says...
>>
>> Even on a 64 bit OS, Access is running under the 32 bit emulation mode
>> because it's a 32 bit application and therefore, the same connection
>> string
>> should always work for both 32 and 64 bit OS to connect to an instance of
>> SQL-Server from Access.
>>
>> Furthermore, if I remember correctly, the Express edition of SQL-Server
>> 2005
>> can only be installed under the 32 bit mode; contrary to the Express
>> edition
>> of SQL-Server 2008 which can be installed to run natively under the 64
>> bit
>> mode.
>>
>> Second, you should check the protocol that you are using. With
>> SQL-Server,
>> three different protocols can be used: the Shared Memory protocol, the
>> Named
>> Pipe protocol or TCP/IP. Maybe you have a configuration problem at this
>> level. For example, if TCP/IP is set to be the default protocol to be
>> used
>> but that it has been inactivated in the configuraton of the SQL-Server,
>> then
>> you won't be able to connect. You should check your configuration to see
>> what protocols have been activated.
>>
>> Finally, when you have a connection problem, you should tell us what your
>> exact situation. For example, if you can connect using a DSN connection,
>> then you should told us as this can eliminate some possibilities. Same
>> thing if you can connect using another program such as SQL Server
>> Management
>> Studio (SSMS) or if you can connect or not from another machine. Make
>> sure
>> also that the SQL-Server Service is running properly. If it has not be
>> started, you won't be able to connect to it from Access. While checking
>> the
>> service, take the time to verify that its name is SQLExpress and not
>> something else and an unnamed instance.
>
> Yes the server is started; dsn connections work fine as I noted many
> times. tcp/ip. Names in the string are good.

The fact that you can create and use a DSN to connect to the sql-server
eliminates many possibilities but I don't remember seeing a case where you
can connect using a DSN but not using a DSN-less connection. (But the
contrary - to be able to connect with a DSN-less conection but not with a
DSN - is quite frequent.)

I would suggest that you create aliases in order to precisely test for the
protocol to be used. Create both a DSN and DSN-Less connections using each
time the same alias and probably that you will find where the error is.

You can create aliases using the Configuration Tool of SQL-Server 2005.

Also, double check to be sure that you are really using the very same ODBC
provider each time.

--
Sylvain Lafontaine, ing.
MVP - Windows Live Platform
Blog/web site: http://coding-paparazzi.sylvainlafontaine.com
Independent consultant and remote programming for Access and SQL-Server
(French)



First  |  Prev  | 
Pages: 1 2 3
Prev: Calculating comboboxes
Next: How to find the name of the present subform