Accessing a DSN through a Sql job

I am trying to execute an SSIS package (which accesses a dbf file through an odbc connection) through a Sql job, but the package log reports an error of "Disk or netowrk error". When I execute the package in the IDE, the package executes fine. When I run the manifest on the DB server, I can execute the package with no errors. But, when I create the job, and try to execute the job, it fails. I thought at first that the user didn't have privileges to the directory that the file existed in, but that isn't the case.

Can anyone shed some light on how to accomplish what I am trying to accomplish? It seems like this would be a common use of SSIS, but I cannot seem to get it to work.

Thanks in advance for any assistance you can provide!

Craig

This seems to be security issue, as your package can execute fine within the IDE, but not through the SQL Agent. I'd check the SQL Agent user account, along with the proxy details on the job.

|||

Thank you for your reply, Deniz.

Do you know of any web sites that I can get more information on setting up the Sql Agent account permissions? I granted that user admin privileges, but still receive the same error.

Craig Browder

craigster1976@.msn.com

Access to the remote server is denied because the current security context is not trusted.

Hi all,
What I did:
Created a SQL Job that accesses another database on some other server.
I get the error:
Access to the remote server is denied because the current security
context is not trusted. [SQLSTATE 42000] (Error 15274).
I have the remote server as the linked server to my local server.
The login account used for the job step is present on both the servers
(with the role sysadmin)
Any pointers?
All help would be appreciated.
Thanks in anticipation,
Vivek Balagangadharan
Software Engineer,
Fast Track Software Services,
India
Forgot to mention one thing:
I tried executing the same query through my management studio with the
same login, and it works great.
It also works when i try using it from my web application.
But, it doesnt work when i use a SQL job
Thanks,
Vivek Balagangadharan
Software Engineer,
Fast Track Software Services,
India
|||Hi Vivek,
How is security defined on that linked server? Are you using Intergrated
Security (Windows account) or are you using SQL server authentication.
If you are using Intergrated security, then make sure that the account
that runs your SQL Server Agent service has proper rights to the linked
server (is Trusted for delegation).
Regards
Steen Schlter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Hi all,
> What I did:
> Created a SQL Job that accesses another database on some other server.
> I get the error:
> Access to the remote server is denied because the current security
> context is not trusted. [SQLSTATE 42000] (Error 15274).
> I have the remote server as the linked server to my local server.
> The login account used for the job step is present on both the servers
> (with the role sysadmin)
> Any pointers?
> All help would be appreciated.
> Thanks in anticipation,
> Vivek Balagangadharan
> Software Engineer,
> Fast Track Software Services,
> India
>
|||Thanks Steen.
I am using SQL authentication and my user is present on both the DB
servers with the role sysadmin.
Now, both these DB servers are on different domains.
But, that still does not explain why it runs from the studio, but not
from the SQL job.
Thanks,
Vivek Balagangadharan
|||And to provide you with more info on the linked server setting, i just
"scripted" the create query for this.
/****** Object: LinkedServer [DB Server 2] Script Date: 06/22/2007
13:02:52 ******/
EXEC master.dbo.sp_addlinkedserver @.server = N'DB Server 2',
@.srvproduct=N'SQL Server'
/* For security reasons the linked server remote logins password is
changed with #### */
EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
2',@.useself=N'False',@.locallogin=NULL,@.rmtuser=N'l ogin1',@.rmtpassword='####'
EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
2',@.useself=N'False',@.locallogin=N'login1',@.rmtuse r=N'login1',@.rmtpassword='####'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'collation compatible', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'data access', @.optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'dist', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'pub', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'rpc', @.optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'rpc
out', @.optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'sub', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'connect timeout', @.optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'collation name', @.optvalue=null
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'lazy schema validation', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'query timeout', @.optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'use
remote collation', @.optvalue=N'true'
|||Hi
I can see that your script creates 2 linkedserver logins where one of
them has a locallogin specified. I'd try to create the linked server
without a local login specified and see if that works (or just drop the
login with a local login specified).
Regards
Steen Schlter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> And to provide you with more info on the linked server setting, i just
> "scripted" the create query for this.
> /****** Object: LinkedServer [DB Server 2] Script Date: 06/22/2007
> 13:02:52 ******/
> EXEC master.dbo.sp_addlinkedserver @.server = N'DB Server 2',
> @.srvproduct=N'SQL Server'
> /* For security reasons the linked server remote logins password is
> changed with #### */
> EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
> 2',@.useself=N'False',@.locallogin=NULL,@.rmtuser=N'l ogin1',@.rmtpassword='####'
> EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
> 2',@.useself=N'False',@.locallogin=N'login1',@.rmtuse r=N'login1',@.rmtpassword='####'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'collation compatible', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'data access', @.optvalue=N'true'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'dist', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'pub', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'rpc', @.optvalue=N'true'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'rpc
> out', @.optvalue=N'true'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'sub', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'connect timeout', @.optvalue=N'0'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'collation name', @.optvalue=null
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'lazy schema validation', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'query timeout', @.optvalue=N'0'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'use
> remote collation', @.optvalue=N'true'
>
|||Thanks Steen.
Yes, initially i had not created any linked server login. But, the job
started failing. That is when i created a linked server login, but
that didn't help either.
I even tried to impersonate a login (since the login was available on
both the servers).
Even forced the connections to use a fixed context (by specifying a
remote server login credential)
This did not work either.
The question that is bothering me is, why is it that the context is
trusted when i use the management studio, but not trusted when i use a
SQL job? (though i use the same login)
Thanks,
Vivek Balagangadharan
|||hmmmm...that sounds a bit strange.
What does the job/script actually do? Could it be that it is trying to
do something on the local/source server that the job hasn't got access
to and that's the error you see rather than an error on the remote
server. I know the error meesage indicates something else, but you never
know..:-).
From where are you executing the job? If you are starting it from your
local PC, could you then try to log on to the server (with e.g. Remote
Desktop) and try to start it from there?
Regards
Steen Schlter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Thanks Steen.
> Yes, initially i had not created any linked server login. But, the job
> started failing. That is when i created a linked server login, but
> that didn't help either.
> I even tried to impersonate a login (since the login was available on
> both the servers).
> Even forced the connections to use a fixed context (by specifying a
> remote server login credential)
> This did not work either.
> The question that is bothering me is, why is it that the context is
> trusted when i use the management studio, but not trusted when i use a
> SQL job? (though i use the same login)
> Thanks,
> Vivek Balagangadharan
>
|||Thanks for the reply Steen.
Well, all the job has/should do, is a simple "select count(*) from [DB
Server 2].[DB_name].[dbo].[table_name]" query.
In my job step, I have specified to "run as user" login1, which is
present on both the DBs and belongs to the sysadmin role group.
I was initially running the job from my management studio (which is
not the server which has the job)
Then, I moved to the local server which actually had the SQL Server
agent, created the job all over again (the owner being login1). But,
no success.
I hope I have answered your queries. Let me know if there is some
confusion.
Thanks,
Vivek Balagangadharan
|||Have you tried running the job without specifying a proxy account (Run
As account)?
Regards
Steen Schlter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Thanks for the reply Steen.
> Well, all the job has/should do, is a simple "select count(*) from [DB
> Server 2].[DB_name].[dbo].[table_name]" query.
> In my job step, I have specified to "run as user" login1, which is
> present on both the DBs and belongs to the sysadmin role group.
> I was initially running the job from my management studio (which is
> not the server which has the job)
> Then, I moved to the local server which actually had the SQL Server
> agent, created the job all over again (the owner being login1). But,
> no success.
> I hope I have answered your queries. Let me know if there is some
> confusion.
> Thanks,
> Vivek Balagangadharan
>

Access to the remote server is denied because the current security context is not trusted.

Hi all,
What I did:
Created a SQL Job that accesses another database on some other server.
I get the error:
Access to the remote server is denied because the current security
context is not trusted. [SQLSTATE 42000] (Error 15274).
I have the remote server as the linked server to my local server.
The login account used for the job step is present on both the servers
(with the role sysadmin)
Any pointers?
All help would be appreciated.
Thanks in anticipation,
Vivek Balagangadharan
Software Engineer,
Fast Track Software Services,
IndiaForgot to mention one thing:
I tried executing the same query through my management studio with the
same login, and it works great.
It also works when i try using it from my web application.
But, it doesnt work when i use a SQL job :(
Thanks,
Vivek Balagangadharan
Software Engineer,
Fast Track Software Services,
India|||Hi Vivek,
How is security defined on that linked server? Are you using Intergrated
Security (Windows account) or are you using SQL server authentication.
If you are using Intergrated security, then make sure that the account
that runs your SQL Server Agent service has proper rights to the linked
server (is Trusted for delegation).
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Hi all,
> What I did:
> Created a SQL Job that accesses another database on some other server.
> I get the error:
> Access to the remote server is denied because the current security
> context is not trusted. [SQLSTATE 42000] (Error 15274).
> I have the remote server as the linked server to my local server.
> The login account used for the job step is present on both the servers
> (with the role sysadmin)
> Any pointers?
> All help would be appreciated.
> Thanks in anticipation,
> Vivek Balagangadharan
> Software Engineer,
> Fast Track Software Services,
> India
>|||Thanks Steen.
I am using SQL authentication and my user is present on both the DB
servers with the role sysadmin.
Now, both these DB servers are on different domains.
But, that still does not explain why it runs from the studio, but not
from the SQL job.
Thanks,
Vivek Balagangadharan|||And to provide you with more info on the linked server setting, i just
"scripted" the create query for this.
/****** Object: LinkedServer [DB Server 2] Script Date: 06/22/2007
13:02:52 ******/
EXEC master.dbo.sp_addlinkedserver @.server = N'DB Server 2',
@.srvproduct=N'SQL Server'
/* For security reasons the linked server remote logins password is
changed with #### */
EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
2',@.useself=N'False',@.locallogin=NULL,@.rmtuser=N'login1',@.rmtpassword='####'
EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
2',@.useself=N'False',@.locallogin=N'login1',@.rmtuser=N'login1',@.rmtpassword='####'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'collation compatible', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'data access', @.optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'dist', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'pub', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'rpc', @.optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'rpc
out', @.optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'sub', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'connect timeout', @.optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'collation name', @.optvalue=null
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'lazy schema validation', @.optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
@.optname=N'query timeout', @.optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'use
remote collation', @.optvalue=N'true'|||Hi
I can see that your script creates 2 linkedserver logins where one of
them has a locallogin specified. I'd try to create the linked server
without a local login specified and see if that works (or just drop the
login with a local login specified).
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> And to provide you with more info on the linked server setting, i just
> "scripted" the create query for this.
> /****** Object: LinkedServer [DB Server 2] Script Date: 06/22/2007
> 13:02:52 ******/
> EXEC master.dbo.sp_addlinkedserver @.server = N'DB Server 2',
> @.srvproduct=N'SQL Server'
> /* For security reasons the linked server remote logins password is
> changed with #### */
> EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
> 2',@.useself=N'False',@.locallogin=NULL,@.rmtuser=N'login1',@.rmtpassword='####'
> EXEC master.dbo.sp_addlinkedsrvlogin @.rmtsrvname=N'DB Server
> 2',@.useself=N'False',@.locallogin=N'login1',@.rmtuser=N'login1',@.rmtpassword='####'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'collation compatible', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'data access', @.optvalue=N'true'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'dist', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'pub', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'rpc', @.optvalue=N'true'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'rpc
> out', @.optvalue=N'true'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'sub', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'connect timeout', @.optvalue=N'0'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'collation name', @.optvalue=null
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'lazy schema validation', @.optvalue=N'false'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2',
> @.optname=N'query timeout', @.optvalue=N'0'
> GO
> EXEC master.dbo.sp_serveroption @.server=N'DB Server 2', @.optname=N'use
> remote collation', @.optvalue=N'true'
>|||Thanks Steen.
Yes, initially i had not created any linked server login. But, the job
started failing. That is when i created a linked server login, but
that didn't help either.
I even tried to impersonate a login (since the login was available on
both the servers).
Even forced the connections to use a fixed context (by specifying a
remote server login credential)
This did not work either.
The question that is bothering me is, why is it that the context is
trusted when i use the management studio, but not trusted when i use a
SQL job? (though i use the same login)
Thanks,
Vivek Balagangadharan|||hmmmm...that sounds a bit strange.
What does the job/script actually do? Could it be that it is trying to
do something on the local/source server that the job hasn't got access
to and that's the error you see rather than an error on the remote
server. I know the error meesage indicates something else, but you never
know..:-).
From where are you executing the job? If you are starting it from your
local PC, could you then try to log on to the server (with e.g. Remote
Desktop) and try to start it from there?
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Thanks Steen.
> Yes, initially i had not created any linked server login. But, the job
> started failing. That is when i created a linked server login, but
> that didn't help either.
> I even tried to impersonate a login (since the login was available on
> both the servers).
> Even forced the connections to use a fixed context (by specifying a
> remote server login credential)
> This did not work either.
> The question that is bothering me is, why is it that the context is
> trusted when i use the management studio, but not trusted when i use a
> SQL job? (though i use the same login)
> Thanks,
> Vivek Balagangadharan
>|||Thanks for the reply Steen.
Well, all the job has/should do, is a simple "select count(*) from [DB
Server 2].[DB_name].[dbo].[table_name]" query.
In my job step, I have specified to "run as user" login1, which is
present on both the DBs and belongs to the sysadmin role group.
I was initially running the job from my management studio (which is
not the server which has the job)
Then, I moved to the local server which actually had the SQL Server
agent, created the job all over again (the owner being login1). But,
no success.
I hope I have answered your queries. Let me know if there is some
confusion.
Thanks,
Vivek Balagangadharan|||Have you tried running the job without specifying a proxy account (Run
As account)?
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Thanks for the reply Steen.
> Well, all the job has/should do, is a simple "select count(*) from [DB
> Server 2].[DB_name].[dbo].[table_name]" query.
> In my job step, I have specified to "run as user" login1, which is
> present on both the DBs and belongs to the sysadmin role group.
> I was initially running the job from my management studio (which is
> not the server which has the job)
> Then, I moved to the local server which actually had the SQL Server
> agent, created the job all over again (the owner being login1). But,
> no success.
> I hope I have answered your queries. Let me know if there is some
> confusion.
> Thanks,
> Vivek Balagangadharan
>|||Thanks, I just tried and it returns me an error that the windows
account is invalid. (Login failed)
That's because the windows account on local server is not available on
remote server.
Thanks,
Vivek Balagangadharan|||That doesn't make sense. When your Linked Server is setup to use a SQl
Server account, then this account needs to exists on the remote server.
When you then use the linked server, it doesn't use any Windows
accounts. I'm accesing a number of remote servers from many different
servers and I'm always using SQL Server authentication for this. Then
there are no Windows/AD account involved. That works fine even to
servers in our DMZ where we (of course) have a seperate domain that
knows nothing about any of our "normal" domains.
Try to set up your linked server to only use SQL Server authentication
and then make sure that the account you are using exists (and with the
same password) on the remote server. Then try to run the query from
QA/Management Studio to verify that it works. Then try to create a job
step that just runs that query and with no Run As/proxy account defined.
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Thanks, I just tried and it returns me an error that the windows
> account is invalid. (Login failed)
> That's because the windows account on local server is not available on
> remote server.
> Thanks,
> Vivek Balagangadharan
>|||Thank you Steen! It works now :D
Actually, it was a combination of a couple of things.
1) Remove the run as 'login1' for the step (which i started trying
after your post :) )
2) Force all the connections to use a fixed context (by specifying
login1 and his password) in the linked server properties.
And I get this message: "Executed as user: NT AUTHORITY\SYSTEM. The
step succeeded."
:) :) :)
Also, in my desperate attempt to get the code working, I had
introduced "Execute as user = 'login1' " in my sql query. I had to do
away with this too.
Thanks for the quick and continuous help.
Cheers,
Vivek Balagangadharan
Software Engineer,
Fast Track Software Services,
India|||Good to hear that it finally worked...:-).
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
vivekbg@.fasttrackteam.com wrote:
> Thank you Steen! It works now :D
> Actually, it was a combination of a couple of things.
> 1) Remove the run as 'login1' for the step (which i started trying
> after your post :) )
> 2) Force all the connections to use a fixed context (by specifying
> login1 and his password) in the linked server properties.
> And I get this message: "Executed as user: NT AUTHORITY\SYSTEM. The
> step succeeded."
> :) :) :)
> Also, in my desperate attempt to get the code working, I had
> introduced "Execute as user = 'login1' " in my sql query. I had to do
> away with this too.
> Thanks for the quick and continuous help.
> Cheers,
> Vivek Balagangadharan
> Software Engineer,
> Fast Track Software Services,
> India
>

Access to SQL 2000 Server database over dialup much slower on XP P

We have an application that accesses a SQL database on a SQL 2000 Server.
When using a dialup (RAS) connection from a W2K workstation with the same
application there is no problem, database information is accessed with 3-5
mins.
Now the same SQL W2K Server with the same database being access by a XP Pro
workstation with the same application over the same dialup connection,
results in much slower performance.
Actually down right terrible, that same information is accessed in 40+mins!
What is it within XP Pro or the ODBC settings or ADO settings that would
impact this transfer so much.
Any ideas?
Thanks.
Tony
Hi
Have you checked the connection speeds to see if they are different?
If you download the MDAC component checker you can verify which versions of
MDAC are being used.
Also make sure that things like server side cursors are being used.
You may want to confirm using profiler that the queries are not different
and they take the same length of time to complete. This may also confirm if
you are setting the options differently.
John
"Tony Saucedo" wrote:

> We have an application that accesses a SQL database on a SQL 2000 Server.
> When using a dialup (RAS) connection from a W2K workstation with the same
> application there is no problem, database information is accessed with 3-5
> mins.
> Now the same SQL W2K Server with the same database being access by a XP Pro
> workstation with the same application over the same dialup connection,
> results in much slower performance.
> Actually down right terrible, that same information is accessed in 40+mins!
> What is it within XP Pro or the ODBC settings or ADO settings that would
> impact this transfer so much.
> Any ideas?
> Thanks.
> Tony

Access to SQL 2000 Server database over dialup much slower on XP P

We have an application that accesses a SQL database on a SQL 2000 Server.
When using a dialup (RAS) connection from a W2K workstation with the same
application there is no problem, database information is accessed with 3-5
mins.
Now the same SQL W2K Server with the same database being access by a XP Pro
workstation with the same application over the same dialup connection,
results in much slower performance.
Actually down right terrible, that same information is accessed in 40+mins!
What is it within XP Pro or the ODBC settings or ADO settings that would
impact this transfer so much.
Any ideas?
Thanks.
TonyHi
Have you checked the connection speeds to see if they are different?
If you download the MDAC component checker you can verify which versions of
MDAC are being used.
Also make sure that things like server side cursors are being used.
You may want to confirm using profiler that the queries are not different
and they take the same length of time to complete. This may also confirm if
you are setting the options differently.
John
"Tony Saucedo" wrote:
> We have an application that accesses a SQL database on a SQL 2000 Server.
> When using a dialup (RAS) connection from a W2K workstation with the same
> application there is no problem, database information is accessed with 3-5
> mins.
> Now the same SQL W2K Server with the same database being access by a XP Pro
> workstation with the same application over the same dialup connection,
> results in much slower performance.
> Actually down right terrible, that same information is accessed in 40+mins!
> What is it within XP Pro or the ODBC settings or ADO settings that would
> impact this transfer so much.
> Any ideas?
> Thanks.
> Tony|||I did not notice the connection speed. I'll check it and the MDAC version. I
would have thought that XP Pro would have had a better version of MDAC, hmmm.
Ok.
If the connection and transfer works better with W2K, does that indicate
that Server side cursor is being used or not. Where can I check this setting?
Do you know if XP handles client-side cursor differently then W2K?
I'll have to try the profiler later since the server is at a remote site.
Thanks.
Tony
"John Bell" wrote:
> Hi
> Have you checked the connection speeds to see if they are different?
> If you download the MDAC component checker you can verify which versions of
> MDAC are being used.
> Also make sure that things like server side cursors are being used.
> You may want to confirm using profiler that the queries are not different
> and they take the same length of time to complete. This may also confirm if
> you are setting the options differently.
> John
> "Tony Saucedo" wrote:
> > We have an application that accesses a SQL database on a SQL 2000 Server.
> > When using a dialup (RAS) connection from a W2K workstation with the same
> > application there is no problem, database information is accessed with 3-5
> > mins.
> >
> > Now the same SQL W2K Server with the same database being access by a XP Pro
> > workstation with the same application over the same dialup connection,
> > results in much slower performance.
> > Actually down right terrible, that same information is accessed in 40+mins!
> >
> > What is it within XP Pro or the ODBC settings or ADO settings that would
> > impact this transfer so much.
> >
> > Any ideas?
> > Thanks.
> > Tony|||Hi Tony
The difference could be in what options are set, although I don't remember
any defaults being different unless on your Windows 2000 system you are
running a very old version. An application change would be the most likely to
change to location of the cursors. I assume you have not changed the database
between these two events?
Also have you checked ODBC tracing is not on?
Is the connection speed any different and are you using the correct drivers?
John
"Tony Saucedo" wrote:
> I did not notice the connection speed. I'll check it and the MDAC version. I
> would have thought that XP Pro would have had a better version of MDAC, hmmm.
> Ok.
> If the connection and transfer works better with W2K, does that indicate
> that Server side cursor is being used or not. Where can I check this setting?
> Do you know if XP handles client-side cursor differently then W2K?
> I'll have to try the profiler later since the server is at a remote site.
> Thanks.
> Tony
> "John Bell" wrote:
> > Hi
> >
> > Have you checked the connection speeds to see if they are different?
> >
> > If you download the MDAC component checker you can verify which versions of
> > MDAC are being used.
> >
> > Also make sure that things like server side cursors are being used.
> >
> > You may want to confirm using profiler that the queries are not different
> > and they take the same length of time to complete. This may also confirm if
> > you are setting the options differently.
> >
> > John
> > "Tony Saucedo" wrote:
> >
> > > We have an application that accesses a SQL database on a SQL 2000 Server.
> > > When using a dialup (RAS) connection from a W2K workstation with the same
> > > application there is no problem, database information is accessed with 3-5
> > > mins.
> > >
> > > Now the same SQL W2K Server with the same database being access by a XP Pro
> > > workstation with the same application over the same dialup connection,
> > > results in much slower performance.
> > > Actually down right terrible, that same information is accessed in 40+mins!
> > >
> > > What is it within XP Pro or the ODBC settings or ADO settings that would
> > > impact this transfer so much.
> > >
> > > Any ideas?
> > > Thanks.
> > > Tony

Access to SQL 2000 Server database over dialup much slower on XP P

We have an application that accesses a SQL database on a SQL 2000 Server.
When using a dialup (RAS) connection from a W2K workstation with the same
application there is no problem, database information is accessed with 3-5
mins.
Now the same SQL W2K Server with the same database being access by a XP Pro
workstation with the same application over the same dialup connection,
results in much slower performance.
Actually down right terrible, that same information is accessed in 40+mins!
What is it within XP Pro or the ODBC settings or ADO settings that would
impact this transfer so much.
Any ideas?
Thanks.
TonyHi
Have you checked the connection speeds to see if they are different?
If you download the MDAC component checker you can verify which versions of
MDAC are being used.
Also make sure that things like server side cursors are being used.
You may want to confirm using profiler that the queries are not different
and they take the same length of time to complete. This may also confirm if
you are setting the options differently.
John
"Tony Saucedo" wrote:

> We have an application that accesses a SQL database on a SQL 2000 Server.
> When using a dialup (RAS) connection from a W2K workstation with the same
> application there is no problem, database information is accessed with 3-5
> mins.
> Now the same SQL W2K Server with the same database being access by a XP Pr
o
> workstation with the same application over the same dialup connection,
> results in much slower performance.
> Actually down right terrible, that same information is accessed in 40+mins
!
> What is it within XP Pro or the ODBC settings or ADO settings that would
> impact this transfer so much.
> Any ideas?
> Thanks.
> Tony

Access SQL Server 2005 database using a published website

Hi all,

I am stuck with a problem using ASP.Net website. I created a website which accesses a database table in SQL Server 2005. The default.aspx is a form which inserts/updates/deletes data from the database. After creating the website I published it to IIS (Inetpub -> wwwroot). When I use Visual Studio 2005 and build the website and start with debugging. the form comes up and i can insert/update or delete the data from the table as I want. Now, as I have the website published I can access the form from another sharepoint website using the url as

/Employee_Data/Default.aspx">http://<mydesktop>/Employee_Data/Default.aspx

the form shows up but I am not able to access any of the database. I do not see any errors either. Once I click on the button the page just refreshes but nothing else happens. I have my web.config as :-

<?

xmlversion="1.0"?>

<

configuration>

<

appSettings/>

<

connectionStrings/>

<

system.web>

<

compilationdebug="true"/>

<

authenticationmode="Windows"/>

</

system.web>

</

configuration>

Am I missing something? Ieven have Anonymous access in the IIS inetpub properties. I can even the database as I am the administrator.... I appreciate your suggestions.

Thanks,

Kavya

Can you post your connection string as well as SQL commands? Can you connect to the SQL Server from the machine (on which you can access the published website) via Management Studio?

Access protection on deployed SQL Server

How can we control the accesses to a SQL Server that has been deployed on customer site? Basically, we do not want user to log in the database server, even as sa, except through our application.

Any recommendation?

Thanks,

Xiaodoudou

Hi!

Actually you cannot protect the data files. So although you might restrict the user / administrators from logging on to the database you cannot prevent them deatching the database and attaching it to another instance, making it possible for them to read the content of the database. YOu would need additional file security and prevent the administrator and all other users from accessing the physical files.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

In your case, I assume you have no control over the customer site - if that's the case, then you cannot enforce access only through your application.

Thanks
Laurentiu