Re: different environment fails to fill a dataset

OK, what I have done since we last talked was to create a SQL Server login
instead of a Windows login. And it has the same issues.

I assume you changed the connection string to not use integrated security as
well? If so and that does not work I am stucka s to what to tell you to
try next. It's pretty tough to trouble shoot something like this without
actually being there and seeing everything that has gone on. If dropping and
re-creating the logins doesn't work I don't know what to say. Sorry.

--
Andrew J. Kelly SQL MVP


"rseedle" <rseedle@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D542EE0D-A7AF-47C9-AD18-5D6BC94F14A3@xxxxxxxxxxxxxxxx
Andrew:
OK, what I have done since we last talked was to create a SQL Server login
instead of a Windows login. And it has the same issues. The Effects
winform
can't access the SQL Server and the Resources winform can access SQL
Server
on the test workstation. They both work fine on my development
workstation.
Mind you both of the tables are in the same database and if you select the
actual table and select the properties menu -> All tasks -> Manage
Permission
the user clearly has the necessary permissions to access the table.

Any ideas ?

Randy

"Andrew J. Kelly" wrote:

Are you sure that the login on the Test system has the database Planit as
one that it has access to and you have the correct permissions in that db
for that user to do what you want? I would drop the user and the login
on
the system that is not working and then re-add the Login ensuring it has
all
the right permissions in that db. If that doesn't work then I don't know
what to tell you.

--
Andrew J. Kelly SQL MVP


"rseedle" <rseedle@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1C22B152-8C84-43EE-852B-4352FBDEDB9D@xxxxxxxxxxxxxxxx
Andrew:
These are the connection strings. Effects is the data form that has
problems
on the test workstation but not my development station. Resources is a
data
form which which works correctly on both workstations.

Effects - development workstation
Provider=SQLOLEDB;Integrated Security=SSPI;Packet Size=4096;Data
Source=Randy-Other\RSeedle;Initial Catalog=Planit

Resources - development workstation
Provider=SQLOLEDB;Integrated Security=SSPI;Packet Size=4096;Data
Source=Randy-Other\RSeedle;Initial Catalog=Planit


Effects - test workstation
Provider=SQLOLEDB;Integrated Security=SSPI;Packet Size=4096;Data
Source=(local);Initial Catalog=Planit

Resources - test workstation
Provider=SQLOLEDB;Integrated Security=SSPI;Packet Size=4096;Data
Source=(local);Initial Catalog=Planit

I did check, there is a semicolon after the "Initial Catalog=Planit".
Its
just outside of the string.

Also I have stepped through this code on my development workstation
multiple
times. It never fails. I haven't got a debugger on the test
workstation.
Too
bad there isn't just a very minimal debugger that I could put on the
test
workstation.

Randy

"Andrew J. Kelly" wrote:

Are you sure the connection string are identical? Do they specify a
catalog
(default database)? If not you may want to add it to the connection
string
to ensure it is pointing to the correct db after it connects. Have
you
tried stepping thru the code with the debugger?

--
Andrew J. Kelly SQL MVP


"rseedle" <rseedle@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7468B2A8-98A0-4E7E-9239-B90303EEEA5F@xxxxxxxxxxxxxxxx
Andrew:
All the forms are data forms generated by Visual Studio using C#.
The
difference between them is that they access/update a different
tables
within
a single database. All the connection strings in all the forms are
the
same.

I ran the profiler as requested. The one data form that doesn't work
never
runs the select command. As if it never got it to begin with while
the
others
successfully ran the select command with no problems. I could email
the
trace
files to you if it would help you understand this better.

Randy

"Andrew J. Kelly" wrote:

What exactly is different about that form from the rest? Have you
tried
running profiler to see what is actually happening on the sql
server
side?

--
Andrew J. Kelly SQL MVP


"rseedle" <rseedle@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:51D13828-57D3-4375-9F6B-AA23BC9C738C@xxxxxxxxxxxxxxxx
Andrew:
Well I recreated the login but it didn't make any difference. The
form
that
didn't work before still doesn't work and the forms that did work
before
still work. Any other suggestions ?

Randy


"Andrew J. Kelly" wrote:

You might have lost the relationship of the Login to the user in
the
db.
It
may be able to connect but not get to the db itself. Try
dropping
the
login
and readding it making sure to specify the database access when
you
do.

--
Andrew J. Kelly SQL MVP


"rseedle" <rseedle@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:58084FB0-43E4-480D-B328-E2633EEF4CCE@xxxxxxxxxxxxxxxx
I am using "Integrated Security=SSPI;" (Windows login info) in
all
of
the
connection strings used in the various forms. Will it still be
necessary
to
do something with sp_change_users_login ?

Randy

"Andrew J. Kelly" wrote:

Did you resync the logins to the users in that db after you
attached
it?
If
not check out sp_change_users_login in BooksOnLine.

--
Andrew J. Kelly SQL MVP


"rseedle" <rseedle@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:C298B6AF-C57D-40EE-905C-CB50F29126F3@xxxxxxxxxxxxxxxx
I have a C# client application that uses SQL Server as a
backend.
It
works
fine on my development workstation. But when I moved it to
another
test
workstation four out of the five winforms worked fine but
one
doesn't.
The
one that doesn't can open the connection and return the
server
version
as
a
test of whether the open worked right. I does. But when you
run
the
oledbadapter.fill command to fill the dataset it fails. It
acts
as
if
it
can't open the server. Further reading shows that the fill
command
can
actually open a connection on its own if necessary without
the
open
command.
Is there anything in the environment or SQL Server that
could
be
causing
this
rejection. The SQL Server database was detached, copied,
and
then
reattached
on the test workstation. SO it should be a duplicate.

Randy

















.

Relevant Pages

  • Re: different environment fails to fill a dataset
    ... These are the connection strings. ... on the test workstation but not my development station. ... Andrew J. Kelly SQL MVP ...
    (microsoft.public.sqlserver.clients)
  • Re: Anonymous Login for Web Visitors
    ... Then check security on all of the system folders to ... > FROM MY WORKSTATION, for the first time since the conversion, I was able ... > supplied by administrator login information. ... > (When I try to open the web with FrontPage & login as administrator, ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Anonymous Login for Web Visitors
    ... >>> pops up for login info. SO, I remembered that during the conversion to ... >>> FROM MY WORKSTATION, for the first time since the conversion, I was ... >>> supplied by administrator login information. ... Does the page start to render and you see data but stops at a ...
    (microsoft.public.sharepoint.portalserver)
  • RE: Anonymous Login for Web Visitors
    ... FROM MY WORKSTATION, for the first time since the conversion, I was able to ... supplied by administrator login information. ... the administrator login and password and and gain access to the web site. ... Does the page start to render and you see data but stops at a certain ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Anonymous Login for Web Visitors
    ... the anonymous login was set up right in both places, however, the ... >> FROM MY WORKSTATION, for the first time since the conversion, I was able ... >> from outside the network, users do not get the page rendering, and they ... >> the administrator login and password and and gain access to the web site. ...
    (microsoft.public.sharepoint.portalserver)