Sylvain,
Thanks for your reply. I also think that it is a premission problem but the SQL administrator thinks that the permissions have not changed since it was on the other server and cmd.execute worked. I have seen some other sources for this message posted, like having cmd.prepared set to true. I am going to have the permissions double checked. Table modification does not seem to be a problem, just .Execute.
I wonder if something might have gone wrong when the SQL BE was moved from the old machine to the new one?
I don't know how to run the Access FE on my machine and have the data source be the one on a remote server. I only have dialup where I am now. I have been developing use SQL Developer edition and, when I did the work, I could go on campus and repoint my FE to use the network SQL. I would be interested in being able to run on my machine with the BE on the remote machine, even over a slow dialup, since I might be able to debug.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> wrote in message news:uGptitYOGHA.2624[ at ]TK2MSFTNGP12.phx.gbl...
[Quoted Text] > This is a permission problem: the Login account or the required
permissions > have not been set up properly on the remote database. However, permission > problems are one of these things that cannot be set up graphically (ie. > using the GUI interface) from Access ADE; so you have to use DDL statement > or use something else like Enterprise Manager. > > I don't understand what you mean by "Since I am out of state I can not run > against the SQL server that she is using.". EM or any other client tool > shouldn't have any problem to make a remote connection if you don't have a > firewall blocking the port 1433 somewhere along the line. > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: http://cerbermail.com/?QugbLEWINF >
|