Can't see or access tables through linked server

Apparently I am doing something wrong and I don't know what!

I am needing to link a remote Oracle Server to SQL Server 2005.

I have (I think) followed the steps precisely to create the linked

server both by code or through the SQL Server Management Studio and I

get the same results eith way. I can see the linked server and there are no apparent errors but I can't see or access the tables from Oracle.

If I try a Select statement on a table from the linked server I get the

error "Msg 208, Level 16, Stat 1, Server {servername}, Line 1 Invalid

object name"

I am assuming this is a permissions issue but I don't see it. I

am an admin on both the SQL Server DB and the Oracle DB with full

access and I am using windows authentication.

I have mapped local logons to the remote logon and tried almost every

possible combination of security contexts and other users on the local

and linked server but I always get the same result. The Oracle server shows it is linked but I can't get to any table on the linked server.

Any help on this would be really appreciated. I have already spent two days on this.

Thanks in advance.

This kb should help.

support.microsoft.com/kb/280106

|||

I don't think this applies. This KB article only covers up to Windows 2000 and Oracle 8.i.

We have either 2003 server or XP (happening on two machines) and Oracle 10g.

Also, I am not getting any error messages as the article discusses, I just can't see the tables.

Thanks for the help.

sql

Can't save view - linked server

Our customer has an external SQL server on which they want to make a
lookup into a table/view.
I have setup a Linked server and retrieve data from the linked server.
Example:
EXEC sp_addlinkedserver
@.server = 'NPRSQL',
@.srvproduct = 'SQLServer OLEDB Provider',
@.provider = 'SQLOLEDB',
@.datasrc = 'SQL01'
Go
SELECT *
FROM NPRSQL.DTS.dbo.ItemView
However I can "create" the view, get the data, but when I try to save
the view I get the following error:
ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]The
operation could
not be performed because the OLE DB provider 'SQLOLEDB' was unable to
begin a
distributed transaction.[Microsoft][ODBC SQL Server Driver][SQL
Server]
[OLE/DB
provider returned message: New transaction cannot enlist in the
specified transaction
coordinator.]
How can it be that I can get the data but not save the view?
I have tried to make a similarly scenario on the Northwind database,
create a view on the linked server and the "call" this view via a view
on my local server with the same result.
/refdkHi
see this link
http://support.microsoft.com/kb/839279
try this first and let us know
VT
Knowledge is power, share it...
http://oneplace4sql.blogspot.com/
"refdk" <fuhlendorf@.gmail.com> wrote in message
news:1181027684.578393.61140@.o5g2000hsb.googlegroups.com...
> Our customer has an external SQL server on which they want to make a
> lookup into a table/view.
> I have setup a Linked server and retrieve data from the linked server.
> Example:
> EXEC sp_addlinkedserver
> @.server = 'NPRSQL',
> @.srvproduct = 'SQLServer OLEDB Provider',
> @.provider = 'SQLOLEDB',
> @.datasrc = 'SQL01'
> Go
> SELECT *
> FROM NPRSQL.DTS.dbo.ItemView
> However I can "create" the view, get the data, but when I try to save
> the view I get the following error:
> ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]The
> operation could
> not be performed because the OLE DB provider 'SQLOLEDB' was unable to
> begin a
> distributed transaction.[Microsoft][ODBC SQL Server Driver][SQ
L
> Server]
> [OLE/DB
> provider returned message: New transaction cannot enlist in the
> specified transaction
> coordinator.]
> How can it be that I can get the data but not save the view?
> I have tried to make a similarly scenario on the Northwind database,
> create a view on the linked server and the "call" this view via a view
> on my local server with the same result.
>
> /refdk
>|||I had already done most of the stuff in the kb-issue. However, I have
now completed every step but the error persists.
/refdk|||Hi
Can you post the view statement
Regards
VT
Knowledge is power, share it...
http://oneplace4sql.blogspot.com/
"refdk" <fuhlendorf@.gmail.com> wrote in message
news:1181109437.668792.166410@.q75g2000hsh.googlegroups.com...
>I had already done most of the stuff in the kb-issue. However, I have
> now completed every step but the error persists.
> /refdk
>|||SELECT dbo.Hornsh=F8j$Item.No_ AS [No], dbo.Hornsh=F8j
$Item.Description, dbo.Hornsh=F8j$Item.[Unit Price], SUM(dbo.[Hornsh
=F8j
$Item Ledger Entry].Quantity)
AS Quantity
FROM dbo.Hornsh=F8j$Item INNER JOIN
dbo.[Hornsh=F8j$Item Ledger Entry] ON dbo.Hornsh=F8j
$Item.No_ =3D dbo.[Hornsh=F8j$Item Ledger Entry].[Item No_]
GROUP BY dbo.Hornsh=F8j$Item.No_, dbo.Hornsh=F8j$Item.Description,
dbo.Hornsh=F8j$Item.[Unit Price]|||> How can it be that I can get the data but not save the view?
Are you trying to create the view inside of a transaction? Why is it going
through ODBC/OLEDB? Shouldn't you be creating the view in a query window
connected to that server, instead of trying to create the view through your
app via the linked server? (Well, that's how I would do it, anyway.)

Can't save view - linked server

Our customer has an external SQL server on which they want to make a
lookup into a table/view.
I have setup a Linked server and retrieve data from the linked server.
Example:
EXEC sp_addlinkedserver
@.server = 'NPRSQL',
@.srvproduct = 'SQLServer OLEDB Provider',
@.provider = 'SQLOLEDB',
@.datasrc = 'SQL01'
Go
SELECT *
FROM NPRSQL.DTS.dbo.ItemView
However I can "create" the view, get the data, but when I try to save
the view I get the following error:
ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]The
operation could
not be performed because the OLE DB provider 'SQLOLEDB' was unable to
begin a
distributed transaction.[Microsoft][ODBC SQL Server Driver][SQL
Server]
[OLE/DB
provider returned message: New transaction cannot enlist in the
specified transaction
coordinator.]
How can it be that I can get the data but not save the view?
I have tried to make a similarly scenario on the Northwind database,
create a view on the linked server and the "call" this view via a view
on my local server with the same result.
/refdkHi
see this link
http://support.microsoft.com/kb/839279
try this first and let us know
VT
Knowledge is power, share it...
http://oneplace4sql.blogspot.com/
"refdk" <fuhlendorf@.gmail.com> wrote in message
news:1181027684.578393.61140@.o5g2000hsb.googlegroups.com...
> Our customer has an external SQL server on which they want to make a
> lookup into a table/view.
> I have setup a Linked server and retrieve data from the linked server.
> Example:
> EXEC sp_addlinkedserver
> @.server = 'NPRSQL',
> @.srvproduct = 'SQLServer OLEDB Provider',
> @.provider = 'SQLOLEDB',
> @.datasrc = 'SQL01'
> Go
> SELECT *
> FROM NPRSQL.DTS.dbo.ItemView
> However I can "create" the view, get the data, but when I try to save
> the view I get the following error:
> ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]The
> operation could
> not be performed because the OLE DB provider 'SQLOLEDB' was unable to
> begin a
> distributed transaction.[Microsoft][ODBC SQL Server Driver][SQL
> Server]
> [OLE/DB
> provider returned message: New transaction cannot enlist in the
> specified transaction
> coordinator.]
> How can it be that I can get the data but not save the view?
> I have tried to make a similarly scenario on the Northwind database,
> create a view on the linked server and the "call" this view via a view
> on my local server with the same result.
>
> /refdk
>|||I had already done most of the stuff in the kb-issue. However, I have
now completed every step but the error persists.
/refdk|||Hi
Can you post the view statement
Regards
VT
Knowledge is power, share it...
http://oneplace4sql.blogspot.com/
"refdk" <fuhlendorf@.gmail.com> wrote in message
news:1181109437.668792.166410@.q75g2000hsh.googlegroups.com...
>I had already done most of the stuff in the kb-issue. However, I have
> now completed every step but the error persists.
> /refdk
>|||SELECT dbo.Hornsh=F8j$Item.No_ AS [No], dbo.Hornsh=F8j
$Item.Description, dbo.Hornsh=F8j$Item.[Unit Price], SUM(dbo.[Hornsh=F8j
$Item Ledger Entry].Quantity)
AS Quantity
FROM dbo.Hornsh=F8j$Item INNER JOIN
dbo.[Hornsh=F8j$Item Ledger Entry] ON dbo.Hornsh=F8j
$Item.No_ =3D dbo.[Hornsh=F8j$Item Ledger Entry].[Item No_]
GROUP BY dbo.Hornsh=F8j$Item.No_, dbo.Hornsh=F8j$Item.Description,
dbo.Hornsh=F8j$Item.[Unit Price]|||> How can it be that I can get the data but not save the view?
Are you trying to create the view inside of a transaction? Why is it going
through ODBC/OLEDB? Shouldn't you be creating the view in a query window
connected to that server, instead of trying to create the view through your
app via the linked server? (Well, that's how I would do it, anyway.)

Can't save view - linked server

Our customer has an external SQL server on which they want to make a
lookup into a table/view.
I have setup a Linked server and retrieve data from the linked server.
Example:
EXEC sp_addlinkedserver
@.server = 'NPRSQL',
@.srvproduct = 'SQLServer OLEDB Provider',
@.provider = 'SQLOLEDB',
@.datasrc = 'SQL01'
Go
SELECT *
FROM NPRSQL.DTS.dbo.ItemView
However I can "create" the view, get the data, but when I try to save
the view I get the following error:
ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]The
operation could
not be performed because the OLE DB provider 'SQLOLEDB' was unable to
begin a
distributed transaction.[Microsoft][ODBC SQL Server Driver][SQL
Server]
[OLE/DB
provider returned message: New transaction cannot enlist in the
specified transaction
coordinator.]
How can it be that I can get the data but not save the view?
I have tried to make a similarly scenario on the Northwind database,
create a view on the linked server and the "call" this view via a view
on my local server with the same result.
/refdk
I had already done most of the stuff in the kb-issue. However, I have
now completed every step but the error persists.
/refdk
|||SELECT dbo.Hornshj$Item.No_ AS [No], dbo.Hornshj
$Item.Description, dbo.Hornshj$Item.[Unit Price], SUM(dbo.[Hornshj
$Item Ledger Entry].Quantity)
AS Quantity
FROM dbo.Hornshj$Item INNER JOIN
dbo.[Hornshj$Item Ledger Entry] ON dbo.Hornshj
$Item.No_ = dbo.[Hornshj$Item Ledger Entry].[Item No_]
GROUP BY dbo.Hornshj$Item.No_, dbo.Hornshj$Item.Description,
dbo.Hornshj$Item.[Unit Price]
|||> How can it be that I can get the data but not save the view?
Are you trying to create the view inside of a transaction? Why is it going
through ODBC/OLEDB? Shouldn't you be creating the view in a query window
connected to that server, instead of trying to create the view through your
app via the linked server? (Well, that's how I would do it, anyway.)

Can't run OpenQuery against OLAP Database

I'm trying to execute a query against an AS 2000 database from query analyzer. I've created the linked server using the "Microsoft OLE DB Provider for OLAP Services" ("Allow InProcess" checked) but I'm getting an error message: "Could not get the data of the row from the OLE DB provider 'MSOLAP'.
[OLE/DB provider returned message: An unexpected internal error has occurred.]
OLE DB error trace [OLE/DB Provider 'MSOLAP' IRowset::GetData returned 0x80040e21: Data status returned from the provider: [COLUMN_NAME=[Measures].[Act] STATUS=DBSTATUS_E_UNAVAILABLE]]."

Has anyone seen this problem before? Do you know what is needed to fix it? I had been able to execute an OpenQuery against another AS2000 database but that was with another machine and I can't pin point what I did to get it to work (the machine had a lot installed on it and I'm not sure what did the trick).

Any help is greatly appreciated.

Carmen.

Please make sure that AS2000 SP4 client components are installed on that machine. I recall similar bug that was fixed in one of the SPs.|||

Thanks, Irina. All machines involved have SP4 installed on them. I think there is something missing on the client as well as on the server. Here is why:

Old laptop connecting to Server A: OK

Old laptop connecting to Server B: Error

New laptop connecting to Server A: Error

New laptop connecting to Server B: Error

If the problem was only on the new laptop, the old one should be able to connect to Server B. And if the problem was only on Server B, the new laptop should connect to Server A.

Thanks,

Carmen.

|||

Actually, I found that what is different on my old laptop is that it has SP3 instead of SP4.... And I think I read it somewhere about SP4 causing this problem. Does anyone knows of a fix for this?

Thanks,

Carmen

Can't run my scheduled job which accesses a linked server: other options?

I have a stored procedure in a database on a server, and this stored
procedure uses a linked server.
The login I was given is only granted DBO permissions on this database.
I am trying to set this up so that the above stored procedure runs once
per month, so I naturally tried to set up a Job which would do this.
I have discovered from another group that:
"You cannot access a linked server from a TSQL jobstep if you aren't
symin."
So: How can I automatically run this stored procedure once per month
under these conditions?
Thanks,
RyanIn SQL 2000, change the job owner to symin.
In SQL 2005, change the job security context.
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another certification Exam
<ryan_willow@.hotmail.com> wrote in message
news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...
>I have a stored procedure in a database on a server, and this stored
> procedure uses a linked server.
> The login I was given is only granted DBO permissions on this database.
> I am trying to set this up so that the above stored procedure runs once
> per month, so I naturally tried to set up a Job which would do this.
> I have discovered from another group that:
> "You cannot access a linked server from a TSQL jobstep if you aren't
> symin."
> So: How can I automatically run this stored procedure once per month
> under these conditions?
> Thanks,
> Ryan
>|||I'm in SQL 2000.
I cannot change the job owner because my permissions do not allow this.
Apparently a dbo user named 'User' can only create a job with owner
'User'. I am trying to implement this without having to step outside
my dbo security level. Is this going to be possible, and if so how?
Thanks.
Arnie Rowland wrote:
> In SQL 2000, change the job owner to symin.
> In SQL 2005, change the job security context.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another certification Exam
>
> <ryan_willow@.hotmail.com> wrote in message
> news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...|||That will not be possible without coordination with the server
administrator. Since Jobs have the potential for significant performance
issues as well as security issues for the server, the security context for
Jobs is symin. (in SQL2000).
And of course a SQL Server Administrator is probably not going to allow you
to have permission to create or change a job because of the potential that
it could execute any code or activity under the symin security context.
Jobs are a 'Server' level activity -NOT a database level activity. Even if a
job is confined to a single database, it still operates as a server level
activity.
That changes with SQL 2005.
--
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another certification Exam
"Ryan" <ryan_willow@.hotmail.com> wrote in message
news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...
> I'm in SQL 2000.
> I cannot change the job owner because my permissions do not allow this.
> Apparently a dbo user named 'User' can only create a job with owner
> 'User'. I am trying to implement this without having to step outside
> my dbo security level. Is this going to be possible, and if so how?
> Thanks.
> Arnie Rowland wrote:
>|||Very informative, thanks Arnie.
Arnie Rowland wrote:
> That will not be possible without coordination with the server
> administrator. Since Jobs have the potential for significant performance
> issues as well as security issues for the server, the security context for
> Jobs is symin. (in SQL2000).
> And of course a SQL Server Administrator is probably not going to allow yo
u
> to have permission to create or change a job because of the potential that
> it could execute any code or activity under the symin security context.
> Jobs are a 'Server' level activity -NOT a database level activity. Even if
a
> job is confined to a single database, it still operates as a server level
> activity.
> That changes with SQL 2005.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another certification Exam
>
> "Ryan" <ryan_willow@.hotmail.com> wrote in message
> news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...

Can't run my scheduled job which accesses a linked server: other options?

In SQL 2000, change the job owner to sysadmin.
In SQL 2005, change the job security context.
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another certification Exam
<ryan_willow@.hotmail.com> wrote in message
news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...
>I have a stored procedure in a database on a server, and this stored
> procedure uses a linked server.
> The login I was given is only granted DBO permissions on this database.
> I am trying to set this up so that the above stored procedure runs once
> per month, so I naturally tried to set up a Job which would do this.
> I have discovered from another group that:
> "You cannot access a linked server from a TSQL jobstep if you aren't
> sysadmin."
> So: How can I automatically run this stored procedure once per month
> under these conditions?
> Thanks,
> Ryan
>I'm in SQL 2000.
I cannot change the job owner because my permissions do not allow this.
Apparently a dbo user named 'User' can only create a job with owner
'User'. I am trying to implement this without having to step outside
my dbo security level. Is this going to be possible, and if so how?
Thanks.
Arnie Rowland wrote:[vbcol=seagreen]
> In SQL 2000, change the job owner to sysadmin.
> In SQL 2005, change the job security context.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another certification Exam
>
> <ryan_willow@.hotmail.com> wrote in message
> news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...|||That will not be possible without coordination with the server
administrator. Since Jobs have the potential for significant performance
issues as well as security issues for the server, the security context for
Jobs is sysadmin. (in SQL2000).
And of course a SQL Server Administrator is probably not going to allow you
to have permission to create or change a job because of the potential that
it could execute any code or activity under the sysadmin security context.
Jobs are a 'Server' level activity -NOT a database level activity. Even if a
job is confined to a single database, it still operates as a server level
activity.
That changes with SQL 2005.
--
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another certification Exam
"Ryan" <ryan_willow@.hotmail.com> wrote in message
news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...
> I'm in SQL 2000.
> I cannot change the job owner because my permissions do not allow this.
> Apparently a dbo user named 'User' can only create a job with owner
> 'User'. I am trying to implement this without having to step outside
> my dbo security level. Is this going to be possible, and if so how?
> Thanks.
> Arnie Rowland wrote:
>|||Very informative, thanks Arnie.
Arnie Rowland wrote:[vbcol=seagreen]
> That will not be possible without coordination with the server
> administrator. Since Jobs have the potential for significant performance
> issues as well as security issues for the server, the security context for
> Jobs is sysadmin. (in SQL2000).
> And of course a SQL Server Administrator is probably not going to allow yo
u
> to have permission to create or change a job because of the potential that
> it could execute any code or activity under the sysadmin security context.
> Jobs are a 'Server' level activity -NOT a database level activity. Even if
a
> job is confined to a single database, it still operates as a server level
> activity.
> That changes with SQL 2005.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another certification Exam
>
> "Ryan" <ryan_willow@.hotmail.com> wrote in message
> news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...|||I have a stored procedure in a database on a server, and this stored
procedure uses a linked server.
The login I was given is only granted DBO permissions on this database.
I am trying to set this up so that the above stored procedure runs once
per month, so I naturally tried to set up a Job which would do this.
I have discovered from another group that:
"You cannot access a linked server from a TSQL jobstep if you aren't
sysadmin."
So: How can I automatically run this stored procedure once per month
under these conditions?
Thanks,
Ryan|||In SQL 2000, change the job owner to sysadmin.
In SQL 2005, change the job security context.
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another certification Exam
<ryan_willow@.hotmail.com> wrote in message
news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...
>I have a stored procedure in a database on a server, and this stored
> procedure uses a linked server.
> The login I was given is only granted DBO permissions on this database.
> I am trying to set this up so that the above stored procedure runs once
> per month, so I naturally tried to set up a Job which would do this.
> I have discovered from another group that:
> "You cannot access a linked server from a TSQL jobstep if you aren't
> sysadmin."
> So: How can I automatically run this stored procedure once per month
> under these conditions?
> Thanks,
> Ryan
>|||I'm in SQL 2000.
I cannot change the job owner because my permissions do not allow this.
Apparently a dbo user named 'User' can only create a job with owner
'User'. I am trying to implement this without having to step outside
my dbo security level. Is this going to be possible, and if so how?
Thanks.
Arnie Rowland wrote:[vbcol=seagreen]
> In SQL 2000, change the job owner to sysadmin.
> In SQL 2005, change the job security context.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another certification Exam
>
> <ryan_willow@.hotmail.com> wrote in message
> news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...|||That will not be possible without coordination with the server
administrator. Since Jobs have the potential for significant performance
issues as well as security issues for the server, the security context for
Jobs is sysadmin. (in SQL2000).
And of course a SQL Server Administrator is probably not going to allow you
to have permission to create or change a job because of the potential that
it could execute any code or activity under the sysadmin security context.
Jobs are a 'Server' level activity -NOT a database level activity. Even if a
job is confined to a single database, it still operates as a server level
activity.
That changes with SQL 2005.
--
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another certification Exam
"Ryan" <ryan_willow@.hotmail.com> wrote in message
news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...
> I'm in SQL 2000.
> I cannot change the job owner because my permissions do not allow this.
> Apparently a dbo user named 'User' can only create a job with owner
> 'User'. I am trying to implement this without having to step outside
> my dbo security level. Is this going to be possible, and if so how?
> Thanks.
> Arnie Rowland wrote:
>|||Very informative, thanks Arnie.
Arnie Rowland wrote:[vbcol=seagreen]
> That will not be possible without coordination with the server
> administrator. Since Jobs have the potential for significant performance
> issues as well as security issues for the server, the security context for
> Jobs is sysadmin. (in SQL2000).
> And of course a SQL Server Administrator is probably not going to allow yo
u
> to have permission to create or change a job because of the potential that
> it could execute any code or activity under the sysadmin security context.
> Jobs are a 'Server' level activity -NOT a database level activity. Even if
a
> job is confined to a single database, it still operates as a server level
> activity.
> That changes with SQL 2005.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another certification Exam
>
> "Ryan" <ryan_willow@.hotmail.com> wrote in message
> news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...

Can't run my scheduled job which accesses a linked server: other options?

I have a stored procedure in a database on a server, and this stored
procedure uses a linked server.
The login I was given is only granted DBO permissions on this database.
I am trying to set this up so that the above stored procedure runs once
per month, so I naturally tried to set up a Job which would do this.
I have discovered from another group that:
"You cannot access a linked server from a TSQL jobstep if you aren't
sysadmin."
So: How can I automatically run this stored procedure once per month
under these conditions?
Thanks,
RyanIn SQL 2000, change the job owner to sysadmin.
In SQL 2005, change the job security context.
--
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another Certification Exam
<ryan_willow@.hotmail.com> wrote in message
news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...
>I have a stored procedure in a database on a server, and this stored
> procedure uses a linked server.
> The login I was given is only granted DBO permissions on this database.
> I am trying to set this up so that the above stored procedure runs once
> per month, so I naturally tried to set up a Job which would do this.
> I have discovered from another group that:
> "You cannot access a linked server from a TSQL jobstep if you aren't
> sysadmin."
> So: How can I automatically run this stored procedure once per month
> under these conditions?
> Thanks,
> Ryan
>|||I'm in SQL 2000.
I cannot change the job owner because my permissions do not allow this.
Apparently a dbo user named 'User' can only create a job with owner
'User'. I am trying to implement this without having to step outside
my dbo security level. Is this going to be possible, and if so how?
Thanks.
Arnie Rowland wrote:
> In SQL 2000, change the job owner to sysadmin.
> In SQL 2005, change the job security context.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another Certification Exam
>
> <ryan_willow@.hotmail.com> wrote in message
> news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...
> >I have a stored procedure in a database on a server, and this stored
> > procedure uses a linked server.
> >
> > The login I was given is only granted DBO permissions on this database.
> >
> > I am trying to set this up so that the above stored procedure runs once
> > per month, so I naturally tried to set up a Job which would do this.
> >
> > I have discovered from another group that:
> > "You cannot access a linked server from a TSQL jobstep if you aren't
> > sysadmin."
> >
> > So: How can I automatically run this stored procedure once per month
> > under these conditions?
> >
> > Thanks,
> > Ryan
> >|||That will not be possible without coordination with the server
administrator. Since Jobs have the potential for significant performance
issues as well as security issues for the server, the security context for
Jobs is sysadmin. (in SQL2000).
And of course a SQL Server Administrator is probably not going to allow you
to have permission to create or change a job because of the potential that
it could execute any code or activity under the sysadmin security context.
Jobs are a 'Server' level activity -NOT a database level activity. Even if a
job is confined to a single database, it still operates as a server level
activity.
That changes with SQL 2005.
--
Arnie Rowland, YACE*
"To be successful, your heart must accompany your knowledge."
*Yet Another Certification Exam
"Ryan" <ryan_willow@.hotmail.com> wrote in message
news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...
> I'm in SQL 2000.
> I cannot change the job owner because my permissions do not allow this.
> Apparently a dbo user named 'User' can only create a job with owner
> 'User'. I am trying to implement this without having to step outside
> my dbo security level. Is this going to be possible, and if so how?
> Thanks.
> Arnie Rowland wrote:
>> In SQL 2000, change the job owner to sysadmin.
>> In SQL 2005, change the job security context.
>> --
>> Arnie Rowland, YACE*
>> "To be successful, your heart must accompany your knowledge."
>> *Yet Another Certification Exam
>>
>> <ryan_willow@.hotmail.com> wrote in message
>> news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...
>> >I have a stored procedure in a database on a server, and this stored
>> > procedure uses a linked server.
>> >
>> > The login I was given is only granted DBO permissions on this database.
>> >
>> > I am trying to set this up so that the above stored procedure runs once
>> > per month, so I naturally tried to set up a Job which would do this.
>> >
>> > I have discovered from another group that:
>> > "You cannot access a linked server from a TSQL jobstep if you aren't
>> > sysadmin."
>> >
>> > So: How can I automatically run this stored procedure once per month
>> > under these conditions?
>> >
>> > Thanks,
>> > Ryan
>> >
>|||Very informative, thanks Arnie.
Arnie Rowland wrote:
> That will not be possible without coordination with the server
> administrator. Since Jobs have the potential for significant performance
> issues as well as security issues for the server, the security context for
> Jobs is sysadmin. (in SQL2000).
> And of course a SQL Server Administrator is probably not going to allow you
> to have permission to create or change a job because of the potential that
> it could execute any code or activity under the sysadmin security context.
> Jobs are a 'Server' level activity -NOT a database level activity. Even if a
> job is confined to a single database, it still operates as a server level
> activity.
> That changes with SQL 2005.
> --
> Arnie Rowland, YACE*
> "To be successful, your heart must accompany your knowledge."
> *Yet Another Certification Exam
>
> "Ryan" <ryan_willow@.hotmail.com> wrote in message
> news:1151017863.128715.208750@.g10g2000cwb.googlegroups.com...
> > I'm in SQL 2000.
> >
> > I cannot change the job owner because my permissions do not allow this.
> > Apparently a dbo user named 'User' can only create a job with owner
> > 'User'. I am trying to implement this without having to step outside
> > my dbo security level. Is this going to be possible, and if so how?
> >
> > Thanks.
> >
> > Arnie Rowland wrote:
> >> In SQL 2000, change the job owner to sysadmin.
> >>
> >> In SQL 2005, change the job security context.
> >>
> >> --
> >> Arnie Rowland, YACE*
> >> "To be successful, your heart must accompany your knowledge."
> >>
> >> *Yet Another Certification Exam
> >>
> >>
> >> <ryan_willow@.hotmail.com> wrote in message
> >> news:1151015746.073933.305090@.r2g2000cwb.googlegroups.com...
> >> >I have a stored procedure in a database on a server, and this stored
> >> > procedure uses a linked server.
> >> >
> >> > The login I was given is only granted DBO permissions on this database.
> >> >
> >> > I am trying to set this up so that the above stored procedure runs once
> >> > per month, so I naturally tried to set up a Job which would do this.
> >> >
> >> > I have discovered from another group that:
> >> > "You cannot access a linked server from a TSQL jobstep if you aren't
> >> > sysadmin."
> >> >
> >> > So: How can I automatically run this stored procedure once per month
> >> > under these conditions?
> >> >
> >> > Thanks,
> >> > Ryan
> >> >
> >

Can't run LDAP Query From Remote Machine

Hi all,
I have a SQL 2005 server with a linked server which points to our
active directory. I am able to query the active directory from the
local machine when RDC'ed into the server, but when I run the query
from a remote machine using Management Studio, I get this error:
Msg 7320, Level 16, State 2, Line 1
Cannot execute the query "SELECT *
FROM 'LDAP://prudc/DC=<domain>,DC=com'
" against OLE DB provider "ADSDSOObject" for linked server "ADSI".
The query is:
SELECT *
FROM OPENQUERY( ADSI,
'SELECT *
FROM ''LDAP://prudc/DC=<domain>,DC=com''
'
)
(note I replaced our domain name with <domain> in the above query and
error message)
This issue isn't specific to the above query as I've tried many ldap
queries and they have all worked on the local machine but failed on the
remote machine.
I'm completely stomped on this and would greatly appreciate any help I
can get.
ThanksHi Jim
This was a previous post when someone had the same error
http://tinyurl.com/pjg7s I am not sure how much use it will be!
If the query works on the server then I would expect it to be ok, which
probably leaves permission/access as the main issue. Can you use VB script to
query the AD e.g. using the scripts from http://www.rlmueller.net/?
John
"Jim" wrote:
> Hi all,
> I have a SQL 2005 server with a linked server which points to our
> active directory. I am able to query the active directory from the
> local machine when RDC'ed into the server, but when I run the query
> from a remote machine using Management Studio, I get this error:
>
> Msg 7320, Level 16, State 2, Line 1
> Cannot execute the query "SELECT *
> FROM 'LDAP://prudc/DC=<domain>,DC=com'
> " against OLE DB provider "ADSDSOObject" for linked server "ADSI".
>
> The query is:
> SELECT *
> FROM OPENQUERY( ADSI,
> 'SELECT *
> FROM ''LDAP://prudc/DC=<domain>,DC=com''
> '
> )
> (note I replaced our domain name with <domain> in the above query and
> error message)
>
> This issue isn't specific to the above query as I've tried many ldap
> queries and they have all worked on the local machine but failed on the
> remote machine.
> I'm completely stomped on this and would greatly appreciate any help I
> can get.
> Thanks
>|||Thanks for the help but unfortunately, I've already looked at that post
and the issue is a bit different.
The issue I'm having seems to have something to do with running a query
from a remote machine. So if I run a query on our SQL Server box from
my local desktop machine, I get the error. Running the query directly
on the SQL Server box while RDCed into the machine works flawlessly.
I did try to run a .vbs script from my machine which was able to query
the active directory...thanks for the link =). This leads me to
believe that it has something to do with SQL server security
restricting queries run from remote machines. I ran the surface area
configuration utility and didn't really see anything that jumped out at
me...
Anyone have any ideas?|||Alright, I've figured out a fix..
The AD linked server that I originally created was set to login to AD
with the credentials of the current security context. I changed this
to log in with a specified login and it worked fine. Whats strange is
that I set it to my own login account which I was using to run the
query remotely anyways. I guess SQL server queries ran remotely are
not run under the logged in users' security context after all?
Thanks for your help John =).

Can't run LDAP Query From Remote Machine

Hi all,
I have a SQL 2005 server with a linked server which points to our
active directory. I am able to query the active directory from the
local machine when RDC'ed into the server, but when I run the query
from a remote machine using Management Studio, I get this error:
Msg 7320, Level 16, State 2, Line 1
Cannot execute the query "SELECT *
FROM 'LDAP://prudc/DC=<domain>,DC=com'
" against OLE DB provider "ADSDSOObject" for linked server "ADSI".
The query is:
SELECT *
FROM OPENQUERY( ADSI,
'SELECT *
FROM ''LDAP://prudc/DC=<domain>,DC=com''
'
)
(note I replaced our domain name with <domain> in the above query and
error message)
This issue isn't specific to the above query as I've tried many ldap
queries and they have all worked on the local machine but failed on the
remote machine.
I'm completely stomped on this and would greatly appreciate any help I
can get.
ThanksHi Jim
This was a previous post when someone had the same error
http://tinyurl.com/pjg7s I am not sure how much use it will be!
If the query works on the server then I would expect it to be ok, which
probably leaves permission/access as the main issue. Can you use VB script t
o
query the AD e.g. using the scripts from http://www.rlmueller.net/?
John
"Jim" wrote:

> Hi all,
> I have a SQL 2005 server with a linked server which points to our
> active directory. I am able to query the active directory from the
> local machine when RDC'ed into the server, but when I run the query
> from a remote machine using Management Studio, I get this error:
>
> Msg 7320, Level 16, State 2, Line 1
> Cannot execute the query "SELECT *
> FROM 'LDAP://prudc/DC=<domain>,DC=com'
> " against OLE DB provider "ADSDSOObject" for linked server "ADSI".
>
> The query is:
> SELECT *
> FROM OPENQUERY( ADSI,
> 'SELECT *
> FROM ''LDAP://prudc/DC=<domain>,DC=com''
> '
> )
> (note I replaced our domain name with <domain> in the above query and
> error message)
>
> This issue isn't specific to the above query as I've tried many ldap
> queries and they have all worked on the local machine but failed on the
> remote machine.
> I'm completely stomped on this and would greatly appreciate any help I
> can get.
> Thanks
>|||Thanks for the help but unfortunately, I've already looked at that post
and the issue is a bit different.
The issue I'm having seems to have something to do with running a query
from a remote machine. So if I run a query on our SQL Server box from
my local desktop machine, I get the error. Running the query directly
on the SQL Server box while RDCed into the machine works flawlessly.
I did try to run a .vbs script from my machine which was able to query
the active directory...thanks for the link =). This leads me to
believe that it has something to do with SQL server security
restricting queries run from remote machines. I ran the surface area
configuration utility and didn't really see anything that jumped out at
me...
Anyone have any ideas?|||Alright, I've figured out a fix..
The AD linked server that I originally created was set to login to AD
with the credentials of the current security context. I changed this
to log in with a specified login and it worked fine. Whats strange is
that I set it to my own login account which I was using to run the
query remotely anyways. I guess SQL server queries ran remotely are
not run under the logged in users' security context after all?
Thanks for your help John =).

Can't run LDAP Query From Remote Machine

Hi all,
I have a SQL 2005 server with a linked server which points to our
active directory. I am able to query the active directory from the
local machine when RDC'ed into the server, but when I run the query
from a remote machine using Management Studio, I get this error:
Msg 7320, Level 16, State 2, Line 1
Cannot execute the query "SELECT *
FROM 'LDAP://prudc/DC=<domain>,DC=com'
" against OLE DB provider "ADSDSOObject" for linked server "ADSI".
The query is:
SELECT *
FROM OPENQUERY( ADSI,
'SELECT *
FROM ''LDAP://prudc/DC=<domain>,DC=com''
'
)
(note I replaced our domain name with <domain> in the above query and
error message)
This issue isn't specific to the above query as I've tried many ldap
queries and they have all worked on the local machine but failed on the
remote machine.
I'm completely stomped on this and would greatly appreciate any help I
can get.
Thanks
Hi Jim
This was a previous post when someone had the same error
http://tinyurl.com/pjg7s I am not sure how much use it will be!
If the query works on the server then I would expect it to be ok, which
probably leaves permission/access as the main issue. Can you use VB script to
query the AD e.g. using the scripts from http://www.rlmueller.net/?
John
"Jim" wrote:

> Hi all,
> I have a SQL 2005 server with a linked server which points to our
> active directory. I am able to query the active directory from the
> local machine when RDC'ed into the server, but when I run the query
> from a remote machine using Management Studio, I get this error:
>
> Msg 7320, Level 16, State 2, Line 1
> Cannot execute the query "SELECT *
> FROM 'LDAP://prudc/DC=<domain>,DC=com'
> " against OLE DB provider "ADSDSOObject" for linked server "ADSI".
>
> The query is:
> SELECT *
> FROM OPENQUERY( ADSI,
> 'SELECT *
> FROM ''LDAP://prudc/DC=<domain>,DC=com''
> '
> )
> (note I replaced our domain name with <domain> in the above query and
> error message)
>
> This issue isn't specific to the above query as I've tried many ldap
> queries and they have all worked on the local machine but failed on the
> remote machine.
> I'm completely stomped on this and would greatly appreciate any help I
> can get.
> Thanks
>
|||Thanks for the help but unfortunately, I've already looked at that post
and the issue is a bit different.
The issue I'm having seems to have something to do with running a query
from a remote machine. So if I run a query on our SQL Server box from
my local desktop machine, I get the error. Running the query directly
on the SQL Server box while RDCed into the machine works flawlessly.
I did try to run a .vbs script from my machine which was able to query
the active directory...thanks for the link =). This leads me to
believe that it has something to do with SQL server security
restricting queries run from remote machines. I ran the surface area
configuration utility and didn't really see anything that jumped out at
me...
Anyone have any ideas?
|||Alright, I've figured out a fix..
The AD linked server that I originally created was set to login to AD
with the credentials of the current security context. I changed this
to log in with a specified login and it worked fine. Whats strange is
that I set it to my own login account which I was using to run the
query remotely anyways. I guess SQL server queries ran remotely are
not run under the logged in users' security context after all?
Thanks for your help John =).

Can't query linked Access database specified by UNC

Hello,
I link Access database to sql server 2000 with ole db 4 provider; tell it to
logon with username ADMIN, empty password.
If the database is on a local drive, everything works correctly, I see the
tables of the access database in EM, and I successfully run query like
select * from accessdb...table1
If the database is on a remote drive and is specified by UNC, I still see
the tables in EM when EM runs on the server; but when I run EM on another
machine, focusing the tables under the linked server returns error
0x80004005. Same when I try to run a query (even on the server):
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.
[OLE/DB provider returned message: The Microsoft Jet database engine cannot
open the file '\\server\share\accessdb.mdb'. It is already opened
exclusively by another user, or you need permission to view its data.]
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IDBInitialize::Initialize returned 0x80004005: ].
Sql server is running on domain administrative account. At the same time as
the message is issued, I can log on that account on the server, launch
Access, and successfully open that same remote database using the same UNC
path.
What gives?
thanks,
Vadim Rapp
Polyscience, Inc.The first is to do is ensure that the database is not being
opened exclusively by other users. If that's all fine then
the error is likely related to permissions.
The account accessing the database needs a minimum of
something similar to Create, Destroy, Read, Write (depending
on the OS) on the folder where the mdb and ldb lives so it
can work with the .ldb file. Those are the minimum
permissions needed in general but it depends upon what
version of Access, what version of MDAC, what OS.
If the permissions are correct, you need to drill down
further to the access control and make sure that the account
has change permissions on the folder where the ldb file
resides. Make sure these are correct by explicitly setting
the permissions for the account.
I've seen several places just use a specific folder for just
the mdb (and consequently the ldb) and give the account full
control over that folder to make things less convoluted in
terms of permissions and the requirement for the ldb file.
-Sue
On Mon, 17 Jan 2005 13:35:38 -0600, "Vadim Rapp"
<vrapp@.nospam.polyscience.com> wrote:
>Hello,
>I link Access database to sql server 2000 with ole db 4 provider; tell it to
>logon with username ADMIN, empty password.
>If the database is on a local drive, everything works correctly, I see the
>tables of the access database in EM, and I successfully run query like
>select * from accessdb...table1
>If the database is on a remote drive and is specified by UNC, I still see
>the tables in EM when EM runs on the server; but when I run EM on another
>machine, focusing the tables under the linked server returns error
>0x80004005. Same when I try to run a query (even on the server):
>OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.
>[OLE/DB provider returned message: The Microsoft Jet database engine cannot
>open the file '\\server\share\accessdb.mdb'. It is already opened
>exclusively by another user, or you need permission to view its data.]
>OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
>IDBInitialize::Initialize returned 0x80004005: ].
>Sql server is running on domain administrative account. At the same time as
>the message is issued, I can log on that account on the server, launch
>Access, and successfully open that same remote database using the same UNC
>path.
>What gives?
>
>thanks,
>Vadim Rapp
>Polyscience, Inc.|||Hello Sue:
You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
SH> The first is to do is ensure that the database is not being
SH> opened exclusively by other users. If that's all fine then
SH> the error is likely related to permissions.
I thought that as well; that's why, as I wrote, I manually logged on the sql
server machine, with the same userid as sqlserver; started Access and opened
the same database successfully.
In other words, I manually did exactly what sql server couldn't do, with the
same login id on the same machine.
Vadim|||Yes...but you still need to check the permissions - the
whole ldb thing. And you need to make sure the permissions
are explicitly set. Logging on and starting access and
opening the database manually is not the same thing.
-Sue
On Tue, 18 Jan 2005 16:07:49 -0600, "Vadim Rapp"
<vrapp@.nospam.polyscience.com> wrote:
>Hello Sue:
>You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
> SH> The first is to do is ensure that the database is not being
> SH> opened exclusively by other users. If that's all fine then
> SH> the error is likely related to permissions.
>I thought that as well; that's why, as I wrote, I manually logged on the sql
>server machine, with the same userid as sqlserver; started Access and opened
>the same database successfully.
>In other words, I manually did exactly what sql server couldn't do, with the
>same login id on the same machine.
>Vadim|||Not that it's to much help, but I've seen a similar issue with Excel files.
I never really found a solution other than having the files on the
SQLServer. I've also tried with various accounts that has full admin access
to the server, domain, local machine etc. but to no avail. I'd be happy to
know the solution/reason since it's a bit annoying that I have to put the
files on the SQLServer to make it work.
Regards
Steen
Vadim Rapp wrote:
> Hello Sue:
> You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
>> The first is to do is ensure that the database is not being
>> opened exclusively by other users. If that's all fine then
>> the error is likely related to permissions.
> I thought that as well; that's why, as I wrote, I manually logged on
> the sql server machine, with the same userid as sqlserver; started
> Access and opened the same database successfully.
> In other words, I manually did exactly what sql server couldn't do,
> with the same login id on the same machine.
> Vadim|||Hello Steen:
You wrote in conference
microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
Fri, 21 Jan 2005 13:02:07 +0100:
SP> Not that it's to much help, but I've seen a similar issue with Excel
SP> files. I never really found a solution other than having the files on
SP> the SQLServer. I've also tried with various accounts that has full
SP> admin access to the server, domain, local machine etc. but to no avail.
SP> I'd be happy to know the solution/reason since it's a bit annoying that
SP> I have to put the files on the SQLServer to make it work.
the only good news is that, as I've found, it works correctly with SQL
Server 2005.
Vadim|||Hello Sue:
You wrote in conference
microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
Tue, 18 Jan 2005 16:11:38 -0700:
SH> Yes...but you still need to check the permissions - the
SH> whole ldb thing. And you need to make sure the permissions
SH> are explicitly set. Logging on and starting access and
SH> opening the database manually is not the same thing.
hmm... if I open the database manually, obviously, Access is creating the
ldb... thus, it can do it... How is it not the same thing?
And it looks like in sql server 2005 it works just fine.
Vadim|||SQL Server does not start up Access and then open up an mdb.
It accesses the mdb.
Just like it's different if you double click a file vs. open
an application and then do a File, Open to open the file.
-Sue
On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
<vr@.myrealbox.nospam.com> wrote:
>Hello Sue:
>You wrote in conference
>microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
>Tue, 18 Jan 2005 16:11:38 -0700:
> SH> Yes...but you still need to check the permissions - the
> SH> whole ldb thing. And you need to make sure the permissions
> SH> are explicitly set. Logging on and starting access and
> SH> opening the database manually is not the same thing.
>hmm... if I open the database manually, obviously, Access is creating the
>ldb... thus, it can do it... How is it not the same thing?
>And it looks like in sql server 2005 it works just fine.
>Vadim|||Vadim,
That last example wasn't a good one. Nonetheless, SQL Server
doesn't start Access and then open a database.
Other than security issues, combinations of MDAC/Jet drivers
can also cause problems and you may want to check those. If
you feel certain that this is a bug in SQL Server, you can
open a case with product support. You will not be charged
for the incident if it is a bug.
-Sue
On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
<vr@.myrealbox.nospam.com> wrote:
>Hello Sue:
>You wrote in conference
>microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
>Tue, 18 Jan 2005 16:11:38 -0700:
> SH> Yes...but you still need to check the permissions - the
> SH> whole ldb thing. And you need to make sure the permissions
> SH> are explicitly set. Logging on and starting access and
> SH> opening the database manually is not the same thing.
>hmm... if I open the database manually, obviously, Access is creating the
>ldb... thus, it can do it... How is it not the same thing?
>And it looks like in sql server 2005 it works just fine.
>Vadim|||one thing that worked for me on loading dumps from UNCs is that i had
to use an absolute UNC path and not the share name.
for example:
if i had a share named "share" on folder X on my C drive
rather than going to //myComputer/share
i had to go to //myComputer/C$/X
and everything worked fine...it is worth a shot.
hth,
hans
Sue Hoegemeier wrote:
> Vadim,
> That last example wasn't a good one. Nonetheless, SQL Server
> doesn't start Access and then open a database.
> Other than security issues, combinations of MDAC/Jet drivers
> can also cause problems and you may want to check those. If
> you feel certain that this is a bug in SQL Server, you can
> open a case with product support. You will not be charged
> for the incident if it is a bug.
> -Sue
> On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
> <vr@.myrealbox.nospam.com> wrote:
> >Hello Sue:
> >You wrote in conference
>microsoft.public.sqlserver.security,microsoft.public.sqlserver.server
on
> >Tue, 18 Jan 2005 16:11:38 -0700:
> >
> > SH> Yes...but you still need to check the permissions - the
> > SH> whole ldb thing. And you need to make sure the permissions
> > SH> are explicitly set. Logging on and starting access and
> > SH> opening the database manually is not the same thing.
> >
> >hmm... if I open the database manually, obviously, Access is
creating the
> >ldb... thus, it can do it... How is it not the same thing?
> >
> >And it looks like in sql server 2005 it works just fine.
> >
> >Vadim

Can't query linked Access database specified by UNC

Hello,
I link Access database to sql server 2000 with ole db 4 provider; tell it to
logon with username ADMIN, empty password.
If the database is on a local drive, everything works correctly, I see the
tables of the access database in EM, and I successfully run query like
select * from accessdb...table1
If the database is on a remote drive and is specified by UNC, I still see
the tables in EM when EM runs on the server; but when I run EM on another
machine, focusing the tables under the linked server returns error
0x80004005. Same when I try to run a query (even on the server):
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.
[OLE/DB provider returned message: The Microsoft Jet database engine cannot
open the file '\\server\share\accessdb.mdb'. It is already opened
exclusively by another user, or you need permission to view its data.]
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IDBInitialize::Initialize returned 0x80004005: ].
Sql server is running on domain administrative account. At the same time as
the message is issued, I can log on that account on the server, launch
Access, and successfully open that same remote database using the same UNC
path.
What gives?
thanks,
Vadim Rapp
Polyscience, Inc.
The first is to do is ensure that the database is not being
opened exclusively by other users. If that's all fine then
the error is likely related to permissions.
The account accessing the database needs a minimum of
something similar to Create, Destroy, Read, Write (depending
on the OS) on the folder where the mdb and ldb lives so it
can work with the .ldb file. Those are the minimum
permissions needed in general but it depends upon what
version of Access, what version of MDAC, what OS.
If the permissions are correct, you need to drill down
further to the access control and make sure that the account
has change permissions on the folder where the ldb file
resides. Make sure these are correct by explicitly setting
the permissions for the account.
I've seen several places just use a specific folder for just
the mdb (and consequently the ldb) and give the account full
control over that folder to make things less convoluted in
terms of permissions and the requirement for the ldb file.
-Sue
On Mon, 17 Jan 2005 13:35:38 -0600, "Vadim Rapp"
<vrapp@.nospam.polyscience.com> wrote:

>Hello,
>I link Access database to sql server 2000 with ole db 4 provider; tell it to
>logon with username ADMIN, empty password.
>If the database is on a local drive, everything works correctly, I see the
>tables of the access database in EM, and I successfully run query like
>select * from accessdb...table1
>If the database is on a remote drive and is specified by UNC, I still see
>the tables in EM when EM runs on the server; but when I run EM on another
>machine, focusing the tables under the linked server returns error
>0x80004005. Same when I try to run a query (even on the server):
>OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.
>[OLE/DB provider returned message: The Microsoft Jet database engine cannot
>open the file '\\server\share\accessdb.mdb'. It is already opened
>exclusively by another user, or you need permission to view its data.]
>OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
>IDBInitialize::Initialize returned 0x80004005: ].
>Sql server is running on domain administrative account. At the same time as
>the message is issued, I can log on that account on the server, launch
>Access, and successfully open that same remote database using the same UNC
>path.
>What gives?
>
>thanks,
>Vadim Rapp
>Polyscience, Inc.
|||Hello Sue:
You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
SH> The first is to do is ensure that the database is not being
SH> opened exclusively by other users. If that's all fine then
SH> the error is likely related to permissions.
I thought that as well; that's why, as I wrote, I manually logged on the sql
server machine, with the same userid as sqlserver; started Access and opened
the same database successfully.
In other words, I manually did exactly what sql server couldn't do, with the
same login id on the same machine.
Vadim
|||Yes...but you still need to check the permissions - the
whole ldb thing. And you need to make sure the permissions
are explicitly set. Logging on and starting access and
opening the database manually is not the same thing.
-Sue
On Tue, 18 Jan 2005 16:07:49 -0600, "Vadim Rapp"
<vrapp@.nospam.polyscience.com> wrote:

>Hello Sue:
>You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
> SH> The first is to do is ensure that the database is not being
> SH> opened exclusively by other users. If that's all fine then
> SH> the error is likely related to permissions.
>I thought that as well; that's why, as I wrote, I manually logged on the sql
>server machine, with the same userid as sqlserver; started Access and opened
>the same database successfully.
>In other words, I manually did exactly what sql server couldn't do, with the
>same login id on the same machine.
>Vadim
|||Not that it's to much help, but I've seen a similar issue with Excel files.
I never really found a solution other than having the files on the
SQLServer. I've also tried with various accounts that has full admin access
to the server, domain, local machine etc. but to no avail. I'd be happy to
know the solution/reason since it's a bit annoying that I have to put the
files on the SQLServer to make it work.
Regards
Steen
Vadim Rapp wrote:
> Hello Sue:
> You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
>
> I thought that as well; that's why, as I wrote, I manually logged on
> the sql server machine, with the same userid as sqlserver; started
> Access and opened the same database successfully.
> In other words, I manually did exactly what sql server couldn't do,
> with the same login id on the same machine.
> Vadim
|||Hello Steen:
You wrote in conference
microsoft.public.sqlserver.security,microsoft.publ ic.sqlserver.server on
Fri, 21 Jan 2005 13:02:07 +0100:
SP> Not that it's to much help, but I've seen a similar issue with Excel
SP> files. I never really found a solution other than having the files on
SP> the SQLServer. I've also tried with various accounts that has full
SP> admin access to the server, domain, local machine etc. but to no avail.
SP> I'd be happy to know the solution/reason since it's a bit annoying that
SP> I have to put the files on the SQLServer to make it work.
the only good news is that, as I've found, it works correctly with SQL
Server 2005.
Vadim
|||Hello Sue:
You wrote in conference
microsoft.public.sqlserver.security,microsoft.publ ic.sqlserver.server on
Tue, 18 Jan 2005 16:11:38 -0700:
SH> Yes...but you still need to check the permissions - the
SH> whole ldb thing. And you need to make sure the permissions
SH> are explicitly set. Logging on and starting access and
SH> opening the database manually is not the same thing.
hmm... if I open the database manually, obviously, Access is creating the
ldb... thus, it can do it... How is it not the same thing?
And it looks like in sql server 2005 it works just fine.
Vadim
|||SQL Server does not start up Access and then open up an mdb.
It accesses the mdb.
Just like it's different if you double click a file vs. open
an application and then do a File, Open to open the file.
-Sue
On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
<vr@.myrealbox.nospam.com> wrote:

>Hello Sue:
>You wrote in conference
>microsoft.public.sqlserver.security,microsoft.pub lic.sqlserver.server on
>Tue, 18 Jan 2005 16:11:38 -0700:
> SH> Yes...but you still need to check the permissions - the
> SH> whole ldb thing. And you need to make sure the permissions
> SH> are explicitly set. Logging on and starting access and
> SH> opening the database manually is not the same thing.
>hmm... if I open the database manually, obviously, Access is creating the
>ldb... thus, it can do it... How is it not the same thing?
>And it looks like in sql server 2005 it works just fine.
>Vadim
|||Vadim,
That last example wasn't a good one. Nonetheless, SQL Server
doesn't start Access and then open a database.
Other than security issues, combinations of MDAC/Jet drivers
can also cause problems and you may want to check those. If
you feel certain that this is a bug in SQL Server, you can
open a case with product support. You will not be charged
for the incident if it is a bug.
-Sue
On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
<vr@.myrealbox.nospam.com> wrote:

>Hello Sue:
>You wrote in conference
>microsoft.public.sqlserver.security,microsoft.pub lic.sqlserver.server on
>Tue, 18 Jan 2005 16:11:38 -0700:
> SH> Yes...but you still need to check the permissions - the
> SH> whole ldb thing. And you need to make sure the permissions
> SH> are explicitly set. Logging on and starting access and
> SH> opening the database manually is not the same thing.
>hmm... if I open the database manually, obviously, Access is creating the
>ldb... thus, it can do it... How is it not the same thing?
>And it looks like in sql server 2005 it works just fine.
>Vadim
|||one thing that worked for me on loading dumps from UNCs is that i had
to use an absolute UNC path and not the share name.
for example:
if i had a share named "share" on folder X on my C drive
rather than going to //myComputer/share
i had to go to //myComputer/C$/X
and everything worked fine...it is worth a shot.
hth,
hans
Sue Hoegemeier wrote:
> Vadim,
> That last example wasn't a good one. Nonetheless, SQL Server
> doesn't start Access and then open a database.
> Other than security issues, combinations of MDAC/Jet drivers
> can also cause problems and you may want to check those. If
> you feel certain that this is a bug in SQL Server, you can
> open a case with product support. You will not be charged
> for the incident if it is a bug.
> -Sue
> On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
> <vr@.myrealbox.nospam.com> wrote:
>
>microsoft.public.sqlserver.security,microsoft.pub lic.sqlserver.server
on[vbcol=seagreen]
creating the[vbcol=seagreen]

Can't query linked Access database specified by UNC

Hello,
I link Access database to sql server 2000 with ole db 4 provider; tell it to
logon with username ADMIN, empty password.
If the database is on a local drive, everything works correctly, I see the
tables of the access database in EM, and I successfully run query like
select * from accessdb...table1
If the database is on a remote drive and is specified by UNC, I still see
the tables in EM when EM runs on the server; but when I run EM on another
machine, focusing the tables under the linked server returns error
0x80004005. Same when I try to run a query (even on the server):
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.
[OLE/DB provider returned message: The Microsoft Jet database engine can
not
open the file '\\server\share\accessdb.mdb'. It is already opened
exclusively by another user, or you need permission to view its data.]
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
IDBInitialize::Initialize returned 0x80004005: ].
Sql server is running on domain administrative account. At the same time as
the message is issued, I can log on that account on the server, launch
Access, and successfully open that same remote database using the same UNC
path.
What gives?
thanks,
Vadim Rapp
Polyscience, Inc.The first is to do is ensure that the database is not being
opened exclusively by other users. If that's all fine then
the error is likely related to permissions.
The account accessing the database needs a minimum of
something similar to Create, Destroy, Read, Write (depending
on the OS) on the folder where the mdb and ldb lives so it
can work with the .ldb file. Those are the minimum
permissions needed in general but it depends upon what
version of Access, what version of MDAC, what OS.
If the permissions are correct, you need to drill down
further to the access control and make sure that the account
has change permissions on the folder where the ldb file
resides. Make sure these are correct by explicitly setting
the permissions for the account.
I've seen several places just use a specific folder for just
the mdb (and consequently the ldb) and give the account full
control over that folder to make things less convoluted in
terms of permissions and the requirement for the ldb file.
-Sue
On Mon, 17 Jan 2005 13:35:38 -0600, "Vadim Rapp"
<vrapp@.nospam.polyscience.com> wrote:

>Hello,
>I link Access database to sql server 2000 with ole db 4 provider; tell it t
o
>logon with username ADMIN, empty password.
>If the database is on a local drive, everything works correctly, I see the
>tables of the access database in EM, and I successfully run query like
>select * from accessdb...table1
>If the database is on a remote drive and is specified by UNC, I still see
>the tables in EM when EM runs on the server; but when I run EM on another
>machine, focusing the tables under the linked server returns error
>0x80004005. Same when I try to run a query (even on the server):
>OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error.
>[OLE/DB provider returned message: The Microsoft Jet database engine ca
nnot
>open the file '\\server\share\accessdb.mdb'. It is already opened
>exclusively by another user, or you need permission to view its data.]
>OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0'
>IDBInitialize::Initialize returned 0x80004005: ].
>Sql server is running on domain administrative account. At the same time as
>the message is issued, I can log on that account on the server, launch
>Access, and successfully open that same remote database using the same UNC
>path.
>What gives?
>
>thanks,
>Vadim Rapp
>Polyscience, Inc.|||Hello Sue:
You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
SH> The first is to do is ensure that the database is not being
SH> opened exclusively by other users. If that's all fine then
SH> the error is likely related to permissions.
I thought that as well; that's why, as I wrote, I manually logged on the sql
server machine, with the same userid as sqlserver; started Access and opened
the same database successfully.
In other words, I manually did exactly what sql server couldn't do, with the
same login id on the same machine.
Vadim|||Yes...but you still need to check the permissions - the
whole ldb thing. And you need to make sure the permissions
are explicitly set. Logging on and starting access and
opening the database manually is not the same thing.
-Sue
On Tue, 18 Jan 2005 16:07:49 -0600, "Vadim Rapp"
<vrapp@.nospam.polyscience.com> wrote:

>Hello Sue:
>You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
> SH> The first is to do is ensure that the database is not being
> SH> opened exclusively by other users. If that's all fine then
> SH> the error is likely related to permissions.
>I thought that as well; that's why, as I wrote, I manually logged on the sq
l
>server machine, with the same userid as sqlserver; started Access and opene
d
>the same database successfully.
>In other words, I manually did exactly what sql server couldn't do, with th
e
>same login id on the same machine.
>Vadim|||Not that it's to much help, but I've seen a similar issue with Excel files.
I never really found a solution other than having the files on the
SQLServer. I've also tried with various accounts that has full admin access
to the server, domain, local machine etc. but to no avail. I'd be happy to
know the solution/reason since it's a bit annoying that I have to put the
files on the SQLServer to make it work.
Regards
Steen
Vadim Rapp wrote:
> Hello Sue:
> You wrote on Tue, 18 Jan 2005 13:23:38 -0700:
>
> I thought that as well; that's why, as I wrote, I manually logged on
> the sql server machine, with the same userid as sqlserver; started
> Access and opened the same database successfully.
> In other words, I manually did exactly what sql server couldn't do,
> with the same login id on the same machine.
> Vadim|||Hello Steen:
You wrote in conference
microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
Fri, 21 Jan 2005 13:02:07 +0100:
SP> Not that it's to much help, but I've seen a similar issue with Excel
SP> files. I never really found a solution other than having the files on
SP> the SQLServer. I've also tried with various accounts that has full
SP> admin access to the server, domain, local machine etc. but to no avail.
SP> I'd be happy to know the solution/reason since it's a bit annoying that
SP> I have to put the files on the SQLServer to make it work.
the only good news is that, as I've found, it works correctly with SQL
Server 2005.
Vadim|||Hello Sue:
You wrote in conference
microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
Tue, 18 Jan 2005 16:11:38 -0700:
SH> Yes...but you still need to check the permissions - the
SH> whole ldb thing. And you need to make sure the permissions
SH> are explicitly set. Logging on and starting access and
SH> opening the database manually is not the same thing.
hmm... if I open the database manually, obviously, Access is creating the
ldb... thus, it can do it... How is it not the same thing?
And it looks like in sql server 2005 it works just fine.
Vadim|||SQL Server does not start up Access and then open up an mdb.
It accesses the mdb.
Just like it's different if you double click a file vs. open
an application and then do a File, Open to open the file.
-Sue
On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
<vr@.myrealbox.nospam.com> wrote:

>Hello Sue:
>You wrote in conference
>microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
>Tue, 18 Jan 2005 16:11:38 -0700:
> SH> Yes...but you still need to check the permissions - the
> SH> whole ldb thing. And you need to make sure the permissions
> SH> are explicitly set. Logging on and starting access and
> SH> opening the database manually is not the same thing.
>hmm... if I open the database manually, obviously, Access is creating the
>ldb... thus, it can do it... How is it not the same thing?
>And it looks like in sql server 2005 it works just fine.
>Vadim|||Vadim,
That last example wasn't a good one. Nonetheless, SQL Server
doesn't start Access and then open a database.
Other than security issues, combinations of MDAC/Jet drivers
can also cause problems and you may want to check those. If
you feel certain that this is a bug in SQL Server, you can
open a case with product support. You will not be charged
for the incident if it is a bug.
-Sue
On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
<vr@.myrealbox.nospam.com> wrote:

>Hello Sue:
>You wrote in conference
>microsoft.public.sqlserver.security,microsoft.public.sqlserver.server on
>Tue, 18 Jan 2005 16:11:38 -0700:
> SH> Yes...but you still need to check the permissions - the
> SH> whole ldb thing. And you need to make sure the permissions
> SH> are explicitly set. Logging on and starting access and
> SH> opening the database manually is not the same thing.
>hmm... if I open the database manually, obviously, Access is creating the
>ldb... thus, it can do it... How is it not the same thing?
>And it looks like in sql server 2005 it works just fine.
>Vadim|||one thing that worked for me on loading dumps from UNCs is that i had
to use an absolute UNC path and not the share name.
for example:
if i had a share named "share" on folder X on my C drive
rather than going to //myComputer/share
i had to go to //myComputer/C$/X
and everything worked fine...it is worth a shot.
hth,
hans
Sue Hoegemeier wrote:
> Vadim,
> That last example wasn't a good one. Nonetheless, SQL Server
> doesn't start Access and then open a database.
> Other than security issues, combinations of MDAC/Jet drivers
> can also cause problems and you may want to check those. If
> you feel certain that this is a bug in SQL Server, you can
> open a case with product support. You will not be charged
> for the incident if it is a bug.
> -Sue
> On Sat, 22 Jan 2005 23:24:46 -0600, "Vadim Rapp"
> <vr@.myrealbox.nospam.com> wrote:
>
>microsoft.public.sqlserver.security,microsoft.public.sqlserver.server
on[vbcol=seagreen]
creating the[vbcol=seagreen]