Jet engine cannot find input table

  • Thread starter Thread starter andy
  • Start date Start date
A

andy

Excuse me for posting again (prior post in General, which
no one answered), however I still have no solution to this:

I have a DB that runs great from my workstation.

I gave other users shortcuts to the same *.MDB, on a
shared drive (with same permissions as I have).

When I use my shortcut to open the .mdb, the .mdb opens,
and when I click on the command button which accesses a
linked table .dbf, all goes well.

When the other users use their shorcuts to open the .mdb,
the .mdb opens, but when they click on the command button
which accesses the linked table .dbf, the following error
dialog box appears:

The Microsoft Jet engine cannot find the input table or
query 'MyFileName#DBF'. Make sure it exists and that
its name is spelled correctly' and then just an OK button

The file 'MyFileName.dbf' is in the same folder, the
name is spelled correctly, and it has a valid
path...otherwise the same would not work for my
workstation.

How do I resolve this? Please help.
God bless you.
 
-----Original Message-----
Excuse me for posting again (prior post in General, which
no one answered), however I still have no solution to this:

I have a DB that runs great from my workstation.

I gave other users shortcuts to the same *.MDB, on a
shared drive (with same permissions as I have).

When I use my shortcut to open the .mdb, the .mdb opens,
and when I click on the command button which accesses a
linked table .dbf, all goes well.

When the other users use their shorcuts to open the .mdb,
the .mdb opens, but when they click on the command button
which accesses the linked table .dbf, the following error
dialog box appears:

The Microsoft Jet engine cannot find the input table or
query 'MyFileName#DBF'. Make sure it exists and that
its name is spelled correctly' and then just an OK button

The file 'MyFileName.dbf' is in the same folder, the
name is spelled correctly, and it has a valid
path...otherwise the same would not work for my
workstation.

How do I resolve this? Please help.
God bless you.
.
Click to expand...
What is the code behind the command button?

Roxie Aho
 
Thank you for helping. The code behind the command button
is:

Private Sub cmdExportTotals_Click()
On Error GoTo Err_cmdExportTotals_Click
Dim stDocName As String
stDocName = "rpt_ExportTotals"
DoCmd.OpenReport stDocName, acPreview
Exit_cmdExportTotals_Click:
Exit Sub
Err_cmdExportTotals_Click:
MsgBox Err.Description
Resume Exit_cmdExportTotals_Click
End Sub

The rpt_ExportTotals report's record source is
qry_ExportTotals, and

The SQL of the qry_ExportTotals query calls the
ExpressTrak table with the following code

SELECT ExpressTrak.BILLING, ExpressTrak.MASTER,
ExpressTrak.CURRENT
FROM ExpressTrak
WHERE (((ExpressTrak.CURRENT)>0));

The ExpressTrak table is a linked table which references a
file named ExpressTrak.dbf which is in the same folder as
the .mdb.
 
Hi Andy,

Is the shared drive mapped to the same letter on all the computers?
Access stores full hardcoded paths for linked tables.

Suppose (for example) that on your computer the shared drive is F: and
the xxx.mdb and yyy.dbf files are in F:\Database\, but on the other
computers the shared drive is G:. You've given the user a shortcut to
G:\Database\xxx.mdb, but when the time comes the linked table will still
expect to find its data in F:\Database\yyy.dbf.

One way to get round this is to set up the linked table(s) and
shortcut(s) using UNC paths instead of Windows ones, i.e.
\\Computername\Sharename\Database\yyy.dbf
Paths like this aren't affected by different drive mapping on different
computers.
 
Thank you John for your reply,

All the workstations did have the same designated drive
letter mapping (u:), however just to make sure, I deleted
the linked dbf, and re-established the linked dbf unsing
the UNC... nothing changed.

To try to resolve this I tried exporting the data in a
different format (since the error msg said that it
counldn't find the dbf). Both Tab text, and CSV works just
fine. I have re-written the users instructions, and thank
God we are up and running. However, I would like to know
why it recognized the .dbf on my, and one other person's
workstation, and not on others. We patched all security,
and other updates to make all the machines equal, and
verified that it was not a permissions issue. Also,
permissions was proved to be the same once the Tab Text,
and CSV formats worked.

Do you have any further ideas? We have moved a copy of
this over to a test folder, and I linked the mdb to the
dbf, and now I also get an error that it can't find the
file!

Thank you. God bless you.
Andy
-----Original Message-----
Hi Andy,

Is the shared drive mapped to the same letter on all the computers?
Access stores full hardcoded paths for linked tables.

Suppose (for example) that on your computer the shared drive is F: and
the xxx.mdb and yyy.dbf files are in F:\Database\, but on the other
computers the shared drive is G:. You've given the user a shortcut to
G:\Database\xxx.mdb, but when the time comes the linked table will still
expect to find its data in F:\Database\yyy.dbf.

One way to get round this is to set up the linked table (s) and
shortcut(s) using UNC paths instead of Windows ones, i.e.
\\Computername\Sharename\Database\yyy.dbf
Paths like this aren't affected by different drive mapping on different
computers.



Thank you for helping. The code behind the command button
is:

Private Sub cmdExportTotals_Click()
On Error GoTo Err_cmdExportTotals_Click
Dim stDocName As String
stDocName = "rpt_ExportTotals"
DoCmd.OpenReport stDocName, acPreview
Exit_cmdExportTotals_Click:
Exit Sub
Err_cmdExportTotals_Click:
MsgBox Err.Description
Resume Exit_cmdExportTotals_Click
End Sub

The rpt_ExportTotals report's record source is
qry_ExportTotals, and

The SQL of the qry_ExportTotals query calls the
ExpressTrak table with the following code

SELECT ExpressTrak.BILLING, ExpressTrak.MASTER,
ExpressTrak.CURRENT
FROM ExpressTrak
WHERE (((ExpressTrak.CURRENT)>0));

The ExpressTrak table is a linked table which references a
file named ExpressTrak.dbf which is in the same folder as
the .mdb.
Click to expand...

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
.
Click to expand...
 
There's always the old problem that for some reason Access expects dbf
files to have old fashioned short (8.3) names and to be in folders with
short names. I didn't think of this before because your machine was
successfully linking.



Thank you John for your reply,

All the workstations did have the same designated drive
letter mapping (u:), however just to make sure, I deleted
the linked dbf, and re-established the linked dbf unsing
the UNC... nothing changed.

To try to resolve this I tried exporting the data in a
different format (since the error msg said that it
counldn't find the dbf). Both Tab text, and CSV works just
fine. I have re-written the users instructions, and thank
God we are up and running. However, I would like to know
why it recognized the .dbf on my, and one other person's
workstation, and not on others. We patched all security,
and other updates to make all the machines equal, and
verified that it was not a permissions issue. Also,
permissions was proved to be the same once the Tab Text,
and CSV formats worked.

Do you have any further ideas? We have moved a copy of
this over to a test folder, and I linked the mdb to the
dbf, and now I also get an error that it can't find the
file!

Thank you. God bless you.
Andy
-----Original Message-----
Hi Andy,

Is the shared drive mapped to the same letter on all the computers?
Access stores full hardcoded paths for linked tables.

Suppose (for example) that on your computer the shared drive is F: and
the xxx.mdb and yyy.dbf files are in F:\Database\, but on the other
computers the shared drive is G:. You've given the user a shortcut to
G:\Database\xxx.mdb, but when the time comes the linked table will still
expect to find its data in F:\Database\yyy.dbf.

One way to get round this is to set up the linked table (s) and
shortcut(s) using UNC paths instead of Windows ones, i.e.
\\Computername\Sharename\Database\yyy.dbf
Paths like this aren't affected by different drive mapping on different
computers.



Thank you for helping. The code behind the command button
is:

Private Sub cmdExportTotals_Click()
On Error GoTo Err_cmdExportTotals_Click
Dim stDocName As String
stDocName = "rpt_ExportTotals"
DoCmd.OpenReport stDocName, acPreview
Exit_cmdExportTotals_Click:
Exit Sub
Err_cmdExportTotals_Click:
MsgBox Err.Description
Resume Exit_cmdExportTotals_Click
End Sub

The rpt_ExportTotals report's record source is
qry_ExportTotals, and

The SQL of the qry_ExportTotals query calls the
ExpressTrak table with the following code

SELECT ExpressTrak.BILLING, ExpressTrak.MASTER,
ExpressTrak.CURRENT
FROM ExpressTrak
WHERE (((ExpressTrak.CURRENT)>0));

The ExpressTrak table is a linked table which references a
file named ExpressTrak.dbf which is in the same folder as
the .mdb.

-----Original Message-----

-----Original Message-----
Excuse me for posting again (prior post in General,
which
no one answered), however I still have no solution to
this:

I have a DB that runs great from my workstation.

I gave other users shortcuts to the same *.MDB, on a
shared drive (with same permissions as I have).

When I use my shortcut to open the .mdb, the .mdb opens,
and when I click on the command button which accesses a
linked table .dbf, all goes well.

When the other users use their shorcuts to open
the .mdb,
the .mdb opens, but when they click on the command
button
which accesses the linked table .dbf, the following
error
dialog box appears:

The Microsoft Jet engine cannot find the input table
or
query 'MyFileName#DBF'. Make sure it exists and that
its name is spelled correctly' and then just an OK
button

The file 'MyFileName.dbf' is in the same folder, the
name is spelled correctly, and it has a valid
path...otherwise the same would not work for my
workstation.

How do I resolve this? Please help.
God bless you.
.
What is the code behind the command button?

Roxie Aho
.
Click to expand...

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.
.
Click to expand...
Click to expand...
 
Back
Top