Let me clarify that. You should only have one Emerald DSN and it should
be a system DSN. I have seen instances where having both caused
> >> ODBC *is* working, as an Access application via Cold Fusion works.
> >How about Access or Cold FUsion to SQL Server via ODBC?
> Untested. No need for it at this time, and we have no application that is
> ready or able to test such a thing.
You may have you network library mis-configured. Until you actually
prove your SQL Server ODBC DSN is correct, can connect, and working,
we can only take guesses. I'm just trying to narrow the possibilities.
> >Sounds like you might have ODBC problems. What account is serv-u
> >running as (system or specified user?).
> Specified user (an Administrator) -- we don't run it as a service, we
> AutoAdminLogin and run it from the startup Group. It is this Admin that
> has an account in the SQL server, and has permissions to the Emerald
> database. This is also how it is set up on the NT 3.51 box that is
> working now. (This one is NT 4.0).
I'm still leaning at OBDC/SQL Server client config for the problem.
Run the SQL Client Configuration utility and see what your
default network transport is and see if you have any configs
in the advanced (you shouldn't).
-- Dale E. Reed Jr. (firstname.lastname@example.org)_________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.emerald.iea.com