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 ac
tually 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 ODB
C 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 SQ
L s
erver on the production database. How can this happen? I don't have an ODB
C 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 happen
ed?
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 thro
ugh Access.
"Sue Hoegemeier" wrote:
> 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 OD
BC set up for the production database on the test machine at all. I did hav
e the same passwords in both SQL servers and I just changed one but what els
e can I do to protect agai
nst this?[vbcol=seagreen]
>|||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 thr
ough 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 h
ave the same passwords in both SQL servers and I just changed one but what e
lse can I do to protect aga
inst this?[vbcol=seagreen]
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment