Thanks for your reply!

I see where you’re going with the stored procedure idea. However, here is
the really weird thing. I created a blank Access mdb with nothing in it. I
then linked to a table in DatabaseB on the SQL Server using an ODBC
connection. Let’s say the user name I’m using is db_user and the password is
something like user51!%. I link to table employee. I open the table. All this
time I’m watching the SQL trace I have running to see if that login failure
shows up. Nothing shows up so far. I close Access entirely and open it up
again. Then I try to open the table. I’m prompted for the database login and
password. I enter them. I can see data in the table fine. I check the SQL
trace and that login failure for “Admin” shows up with MY computer name! I
tried it several times and the same thing happens every time. Weird, huh? I
am stumped!

I also understand what you’re saying about having an “admin” account to a
database. Right now only two people use that particular login and they are IT
personnel. Plus, I was not the one who originally set this whole thing up. I
do know the DBA who did set it up would not allow a login like that unless it
was deemed absolutely necessary. DatabaseA was created by a vendor along
with it’s application. I can’t change the login to something else or the app
would break. Besides, the more I think about this the more I feel it has
absolutely nothing to do with DatabaseA and it’s Admin login. If this login
“went away” or was changed, I think we’d still be seeing this login failure
for Admin. Maybe somehow Access is internally using an Admin Id to get
rights to the data or something along those lines. If that’s true, then why
would it do this and how would we stop it?

Thanks!

"Tom Miller" wrote:

> >. For the last couple of days we've noticed
> > that a particular SQL login keeps failing. Some days it fails 20 to 30
> > times.
> > That's how we noticed it. It's called "admin" and it's only used for one
> > SQL
> > database.
>
> I hope you get an answer. The only thing I know of even remotely that might
> apply is that what your describing is a very common (and certainly bad) way
> (using an "admin" login) to provide access to a DB that is being used by
> multiple people. You can see the security issue I am certain. So you might
> want to poke around and see if a "stored procedure" of some kind is
> generating these symptoms.
>
> Thanks,
> Tom Miller
>
> --
> Try http://www.ChatNFiles.com which has a new telnet chat system and a HUGE
> file downloads collection. Ecard: http://bccs.chatnfiles.com/ecard3.htm
>
>
>
> --
> Posted via a free Usenet account from http://www.teranews.com
>
>