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