When I try to create MS OLE DB connection to SQL Server 2000 from some workstation I can't see server. After 200 sec I'm getting "timeout" message, but when I click "Ok" and try again it get connected fine. It doesn't matter if I'm doing this from Data Link Property or any other application. Always it fails on first time and works for second. I tried to check MDAC with COmCheck, reinstall MDAC even. Still no luck.
Thanks for any help.I am having a similar simptoms when connecting to one of my clients via VPN. May be a stupid question but did you check all the wires?:confused:|||This workstation works fine on a network, what wires you talking about?|||Well, if it's not the wire (network wire going to/coming to/from the NIC), then check the group policy for that workstation. Is any any different from the ones where you don't experience the problem?|||When I try to connect SQL Server 2000, I log on to workstation under my name to avoid all possible security problems, and it [connection to server] is works fine on other workstations uner my name.|||Looks like the two workstations are establishing a connection, when your contact your SQL Server for the first time.
If you close the connection,a nd you start again, it works immediately? Try to go to your SQL Server workstation with your WindowsExplorer, first, and see whether you can see it's directory structure immediately.|||I can see directory structure of my SQL Server machine immediately.
It looks for me like user workstation can't see SQL Server comp for some reasons with first attempt. And if I try to create connection (using any driver!) it takes 200 sec to get timeout message, after that it connects fine (of course I should click "Ok" and click "Test connection" second time). Second time works Ok always. The same thing happends in my VB applications. And yes, If I close application, or Data Link Property window, or any other way to connect to the Server, I will wait another 200 sec for first attempt. So, for user it looks like 200 sec delay, responce for error message without closing application, second attempt - application works fine, despite it open and close connections. If application will closed and reopen again, user should wait again 200 sec. But part of workstations works just fine.
Showing posts with label ole. Show all posts
Showing posts with label ole. Show all posts
Tuesday, March 20, 2012
Sunday, March 11, 2012
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
Wednesday, March 7, 2012
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
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]
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]
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]
Friday, February 24, 2012
Can't login with windows user
Why I can't login to a SQL database with windows username and password (both
in OLE DB and ODBC).
If I try with trusted connection (or windows authentication) with the same
user works, but if I write by hand user name (domain\user) and password I
get "Error in initilizing provider". With SQL users works.
Hi,
For trusted connection you are not supposed to specify the user name and
password.
A single login to Operating system will give you access to SQL Server as
well. All you need is to click the "Windows Authentication" and click OK.
This will allow you to access the SQl Server with the credentials of
currently logged in OS user.
User name and password needs to be provided only for SQL server based
logins.
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:O8x4qMSSEHA.3812@.TK2MSFTNGP11.phx.gbl...
> Why I can't login to a SQL database with windows username and password
(both
> in OLE DB and ODBC).
> If I try with trusted connection (or windows authentication) with the same
> user works, but if I write by hand user name (domain\user) and password I
> get "Error in initilizing provider". With SQL users works.
>
|||But I don't want to access the SQl Server with the credentials of
currently logged in OS user. I need another windows user. Windows not SQL
|||Hi,
We cant enter the user name for the windows based user. A single login to OS
will allow allow to login to sql server.
But you could try this:-
1. Map the network (network mapping) to the SQL server using the Windows
user you need to connect to sql server (This user should have rights in sql
server)
2. Now using query analyzer try to connect.
This uses the mapped users security context to login inside sql server
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:OZcYjreSEHA.644@.tk2msftngp13.phx.gbl...
> But I don't want to access the SQl Server with the credentials of
> currently logged in OS user. I need another windows user. Windows not SQL
>
|||Hi
Please what do you mean by map the network (network mapping) ?
|||Mapping a network drive is to create a namesake, say "J" drive which is
actually pointing to a share across your network, like \\shared1\sqlfiles.
To do so, open Windows explorer, go to the Tools menu, you'll find "Map
network drive" as the 1st option. That option gives you the drive 'letter'
you want to choose, as well as the "folder" which is the network share. You
will of course have to be using a domain account, and that should have
necessary permissions to access that shared folder.
Hope that helps!
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.
in OLE DB and ODBC).
If I try with trusted connection (or windows authentication) with the same
user works, but if I write by hand user name (domain\user) and password I
get "Error in initilizing provider". With SQL users works.
Hi,
For trusted connection you are not supposed to specify the user name and
password.
A single login to Operating system will give you access to SQL Server as
well. All you need is to click the "Windows Authentication" and click OK.
This will allow you to access the SQl Server with the credentials of
currently logged in OS user.
User name and password needs to be provided only for SQL server based
logins.
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:O8x4qMSSEHA.3812@.TK2MSFTNGP11.phx.gbl...
> Why I can't login to a SQL database with windows username and password
(both
> in OLE DB and ODBC).
> If I try with trusted connection (or windows authentication) with the same
> user works, but if I write by hand user name (domain\user) and password I
> get "Error in initilizing provider". With SQL users works.
>
|||But I don't want to access the SQl Server with the credentials of
currently logged in OS user. I need another windows user. Windows not SQL
|||Hi,
We cant enter the user name for the windows based user. A single login to OS
will allow allow to login to sql server.
But you could try this:-
1. Map the network (network mapping) to the SQL server using the Windows
user you need to connect to sql server (This user should have rights in sql
server)
2. Now using query analyzer try to connect.
This uses the mapped users security context to login inside sql server
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:OZcYjreSEHA.644@.tk2msftngp13.phx.gbl...
> But I don't want to access the SQl Server with the credentials of
> currently logged in OS user. I need another windows user. Windows not SQL
>
|||Hi
Please what do you mean by map the network (network mapping) ?
|||Mapping a network drive is to create a namesake, say "J" drive which is
actually pointing to a share across your network, like \\shared1\sqlfiles.
To do so, open Windows explorer, go to the Tools menu, you'll find "Map
network drive" as the 1st option. That option gives you the drive 'letter'
you want to choose, as well as the "folder" which is the network share. You
will of course have to be using a domain account, and that should have
necessary permissions to access that shared folder.
Hope that helps!
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.
Can't login with windows user
Why I can't login to a SQL database with windows username and password (both
in OLE DB and ODBC).
If I try with trusted connection (or windows authentication) with the same
user works, but if I write by hand user name (domain\user) and password I
get "Error in initilizing provider". With SQL users works.Hi,
For trusted connection you are not supposed to specify the user name and
password.
A single login to Operating system will give you access to SQL Server as
well. All you need is to click the "Windows Authentication" and click OK.
This will allow you to access the SQl Server with the credentials of
currently logged in OS user.
User name and password needs to be provided only for SQL server based
logins.
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:O8x4qMSSEHA.3812@.TK2MSFTNGP11.phx.gbl...
> Why I can't login to a SQL database with windows username and password
(both
> in OLE DB and ODBC).
> If I try with trusted connection (or windows authentication) with the same
> user works, but if I write by hand user name (domain\user) and password I
> get "Error in initilizing provider". With SQL users works.
>|||But I don't want to access the SQl Server with the credentials of
currently logged in OS user. I need another windows user. Windows not SQL|||Hi,
We cant enter the user name for the windows based user. A single login to OS
will allow allow to login to sql server.
But you could try this:-
1. Map the network (network mapping) to the SQL server using the Windows
user you need to connect to sql server (This user should have rights in sql
server)
2. Now using query analyzer try to connect.
This uses the mapped users security context to login inside sql server
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:OZcYjreSEHA.644@.tk2msftngp13.phx.gbl...
> But I don't want to access the SQl Server with the credentials of
> currently logged in OS user. I need another windows user. Windows not SQL
>|||Hi
Please what do you mean by map the network (network mapping) ?|||Mapping a network drive is to create a namesake, say "J" drive which is
actually pointing to a share across your network, like \\shared1\sqlfiles.
To do so, open Windows explorer, go to the Tools menu, you'll find "Map
network drive" as the 1st option. That option gives you the drive 'letter'
you want to choose, as well as the "folder" which is the network share. You
will of course have to be using a domain account, and that should have
necessary permissions to access that shared folder.
Hope that helps!
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.
in OLE DB and ODBC).
If I try with trusted connection (or windows authentication) with the same
user works, but if I write by hand user name (domain\user) and password I
get "Error in initilizing provider". With SQL users works.Hi,
For trusted connection you are not supposed to specify the user name and
password.
A single login to Operating system will give you access to SQL Server as
well. All you need is to click the "Windows Authentication" and click OK.
This will allow you to access the SQl Server with the credentials of
currently logged in OS user.
User name and password needs to be provided only for SQL server based
logins.
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:O8x4qMSSEHA.3812@.TK2MSFTNGP11.phx.gbl...
> Why I can't login to a SQL database with windows username and password
(both
> in OLE DB and ODBC).
> If I try with trusted connection (or windows authentication) with the same
> user works, but if I write by hand user name (domain\user) and password I
> get "Error in initilizing provider". With SQL users works.
>|||But I don't want to access the SQl Server with the credentials of
currently logged in OS user. I need another windows user. Windows not SQL|||Hi,
We cant enter the user name for the windows based user. A single login to OS
will allow allow to login to sql server.
But you could try this:-
1. Map the network (network mapping) to the SQL server using the Windows
user you need to connect to sql server (This user should have rights in sql
server)
2. Now using query analyzer try to connect.
This uses the mapped users security context to login inside sql server
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:OZcYjreSEHA.644@.tk2msftngp13.phx.gbl...
> But I don't want to access the SQl Server with the credentials of
> currently logged in OS user. I need another windows user. Windows not SQL
>|||Hi
Please what do you mean by map the network (network mapping) ?|||Mapping a network drive is to create a namesake, say "J" drive which is
actually pointing to a share across your network, like \\shared1\sqlfiles.
To do so, open Windows explorer, go to the Tools menu, you'll find "Map
network drive" as the 1st option. That option gives you the drive 'letter'
you want to choose, as well as the "folder" which is the network share. You
will of course have to be using a domain account, and that should have
necessary permissions to access that shared folder.
Hope that helps!
Vikram Jayaram
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.
Can't login with windows user
Why I can't login to a SQL database with windows username and password (both
in OLE DB and ODBC).
If I try with trusted connection (or windows authentication) with the same
user works, but if I write by hand user name (domain\user) and password I
get "Error in initilizing provider". With SQL users works.Hi,
For trusted connection you are not supposed to specify the user name and
password.
A single login to Operating system will give you access to SQL Server as
well. All you need is to click the "Windows Authentication" and click OK.
This will allow you to access the SQl Server with the credentials of
currently logged in OS user.
User name and password needs to be provided only for SQL server based
logins.
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:O8x4qMSSEHA.3812@.TK2MSFTNGP11.phx.gbl...
> Why I can't login to a SQL database with windows username and password
(both
> in OLE DB and ODBC).
> If I try with trusted connection (or windows authentication) with the same
> user works, but if I write by hand user name (domain\user) and password I
> get "Error in initilizing provider". With SQL users works.
>
in OLE DB and ODBC).
If I try with trusted connection (or windows authentication) with the same
user works, but if I write by hand user name (domain\user) and password I
get "Error in initilizing provider". With SQL users works.Hi,
For trusted connection you are not supposed to specify the user name and
password.
A single login to Operating system will give you access to SQL Server as
well. All you need is to click the "Windows Authentication" and click OK.
This will allow you to access the SQl Server with the credentials of
currently logged in OS user.
User name and password needs to be provided only for SQL server based
logins.
Thanks
Hari
MCDBA
"Sorin Sandu" <ssandu@.bizland.ro.invalid> wrote in message
news:O8x4qMSSEHA.3812@.TK2MSFTNGP11.phx.gbl...
> Why I can't login to a SQL database with windows username and password
(both
> in OLE DB and ODBC).
> If I try with trusted connection (or windows authentication) with the same
> user works, but if I write by hand user name (domain\user) and password I
> get "Error in initilizing provider". With SQL users works.
>
Subscribe to:
Posts (Atom)