Wednesday, 7 March 2012

confused connection-SQL7

I just had a very strange (and scary) experience; on my test machine I have one ODBC set up to connect to my test SQL server. I just realized that some of the tables I have linked to this SQL server in an Access database are actually linked to the SQL se
rver on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect against
this?
Unless you have the same name or IP address or changed the Test server to
Production and kept the same name I'm not sure how this could happend.
Unless there was a change to DNS or WINS that changed the way the machine
names are resolved...
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||It may have just been viewing the tables based on the meta
data stored on the Access side - did you actually select,
insert, update or delete from the tables? .
You can get around this and other issues with linked tables
by using code to reattach the tables when the application
starts.
-Sue
On Sat, 17 Jul 2004 06:38:01 -0700, "PatO"
<PatO@.discussions.microsoft.com> wrote:

>I just had a very strange (and scary) experience; on my test machine I have one ODBC set up to connect to my test SQL server. I just realized that some of the tables I have linked to this SQL server in an Access database are actually linked to the SQL s
erver on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect agains
t this?
|||Thanks for your input. I realized last night that the production server is listed as a remote server on the test server. Could this be how this happened?
Pat
"Kevin McDonnell [MSFT]" wrote:

> Unless you have the same name or IP address or changed the Test server to
> Production and kept the same name I'm not sure how this could happend.
> Unless there was a change to DNS or WINS that changed the way the machine
> names are resolved...
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
|||Thanks for your reply. Yes I actually did update the production tables through Access.
"Sue Hoegemeier" wrote:
[vbcol=seagreen]
> It may have just been viewing the tables based on the meta
> data stored on the Access side - did you actually select,
> insert, update or delete from the tables? .
> You can get around this and other issues with linked tables
> by using code to reattach the tables when the application
> starts.
> -Sue
> On Sat, 17 Jul 2004 06:38:01 -0700, "PatO"
> <PatO@.discussions.microsoft.com> wrote:
server on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect agai
nst this?
>
|||Yes, but you would have had to choose this server during the linking step
in Access.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Then you have the same DSN on the machine which points to
the production server. Or you linked to the production
server. You can find the string used to link the tables in
MSysObjects under the Connect column.
-Sue
On Tue, 20 Jul 2004 05:28:02 -0700, "PatO"
<PatO@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Thanks for your reply. Yes I actually did update the production tables through Access.
>"Sue Hoegemeier" wrote:
L server on the production database. How can this happen? I don't have an ODBC set up for the production database on the test machine at all. I did have the same passwords in both SQL servers and I just changed one but what else can I do to protect aga
inst this?[vbcol=seagreen]

No comments:

Post a Comment