I've developed a program in VB 6 and SQL Server using ADO connections.
I am the owner of the database objects associated with the program.
On one form, I have dropdown combos and dbgrids associated with ADO
data controls. The data controls are connected to the server with ADO
using Windows security, although I've also tried using SQL Server
security with a user ID/password for the program.

The problem is that the dropdowns and grids populate on the
development machine with no problem, but fail to do so when deployed
to other machines on the same domain. I've set up the other users on
the server, giving them all the permissions I can think of without
success.

The development machine is running Windows 2000 and the targer machine
is running Windows XP.

Any ideas would be helpful.

TIA,
Bill Reynolds

Bill Reynolds (TruckeeBill@ltol.com) writes:
> I've developed a program in VB 6 and SQL Server using ADO connections.
> I am the owner of the database objects associated with the program.
> On one form, I have dropdown combos and dbgrids associated with ADO
> data controls. The data controls are connected to the server with ADO
> using Windows security, although I've also tried using SQL Server
> security with a user ID/password for the program.
>
> The problem is that the dropdowns and grids populate on the
> development machine with no problem, but fail to do so when deployed
> to other machines on the same domain. I've set up the other users on
> the server, giving them all the permissions I can think of without
> success.
>
> The development machine is running Windows 2000 and the targer machine
> is running Windows XP.

I guess this is the problem with these Rapid Application Development
techniques. When they work, they work, but when the program fails, you
have no clue what is going on.

There is too little information in your message to say what the problem
might be withour resorting to wild guesses.

The first point would be to augment your program to do proper error
checking. Once you have that rolling, you can find out if there is a
permissions problem. (Of course, you should test your error-handling
with a known error.)

If you have access to the SQL Server Profiler, you can also use this
tool to see what statements that is being generated, and you can also
trace for errors.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Thanks for your response. The problem was typical for VB--the
packaging and deployment wizard didn't include all the files I needed
for SQL Server. I sure wish there were enough Delphi jobs around that
I didn't have to regress to VB. Anyway, after installing the SQL
Server client, the connection worked fine. Now all I have to do is
get Crystal working right.

Bill Reynolds

Erland Sommarskog <esquel@sommarskog.se> wrote in message news:<Xns955DEFEBD1B81Yazorman@127.0.0.1>...
> Bill Reynolds (TruckeeBill@ltol.com) writes:
> > I've developed a program in VB 6 and SQL Server using ADO connections.
> > I am the owner of the database objects associated with the program.
> > On one form, I have dropdown combos and dbgrids associated with ADO
> > data controls. The data controls are connected to the server with ADO
> > using Windows security, although I've also tried using SQL Server
> > security with a user ID/password for the program.
> >
> > The problem is that the dropdowns and grids populate on the
> > development machine with no problem, but fail to do so when deployed
> > to other machines on the same domain. I've set up the other users on
> > the server, giving them all the permissions I can think of without
> > success.
> >
> > The development machine is running Windows 2000 and the targer machine
> > is running Windows XP.
>
> I guess this is the problem with these Rapid Application Development
> techniques. When they work, they work, but when the program fails, you
> have no clue what is going on.
>
> There is too little information in your message to say what the problem
> might be withour resorting to wild guesses.
>
> The first point would be to augment your program to do proper error
> checking. Once you have that rolling, you can find out if there is a
> permissions problem. (Of course, you should test your error-handling
> with a known error.)
>
> If you have access to the SQL Server Profiler, you can also use this
> tool to see what statements that is being generated, and you can also
> trace for errors.