[AccessD] why an .mdb won't connect the same way as secure pivot?

William Thompson william.thompson1 at att.net
Tue Oct 26 10:00:50 CDT 2004


Kind of a touchy problem.  A user actually needs a flat file representation
in an .mdb of data that underlies a pivot table.  The .mdb might have to be
a break from tradition and actually be secure at the file level.

We have a pivot table that is sourced to a (row level) secure stored
procedure in SQL Server.  Funny thing is, the .mdb has trouble drawing data
from the same stored procedure.  It seems Excel has a leg up on secure
connections, or stored procedure calls, or something.  I presume ODBC since
that is the driver in the pivot's connection string.

The Pivot's connection string contains a 'call' to the stored procedure, and
though it was a trusted connection - I'm not sure why - but there was also a
user name in the string.  (The user is no longer with the group by the way).
My fear is that it was set up with a clear text password then had another
call added in by the magic of Excel.

Makes it difficult to set up an .mdb when it doesn't grab a connection that
a pivot table is already grabbing.  Trusted connections do not work.

We can't change anything on the back-end.  Any ideas?  It seems to be
looking like a situation where Excel is able to connect in a more secure way
(and we may have to ditch the .mdb idea).  It seemed at the time a logical
thing, using Access to furnish a flat file that could be stored off
securely.  I've tried pass-through queries, ADO connections, to no avail.

Any suggestions?

Bill Thompson




More information about the AccessD mailing list