Importing a .dbf file into MS Access 2003 - SP3

[brent.hayes]

When attempting to import a .dbf file into MS Access 2003, I receive
an error message. My co-worker, with a similar setup, does not
receive this error. I only received this error after reinstalling my
computer after a hardware crash. I assume I wasn't completely patched
before, thus the reason I was able to use it successfully.

--------------------------------------
Error reads:
"The Microsoft Jet database engine could not find the object 'w300186-
RR.dbf'. Make sure the object exists and that you specify its name
and the path name correctly."
-----------------------------------------
I'm using:
Windows XP Professional (SP2)
Microsoft Office Access 2003 (11.8166.8172) SP3
Microsoft Jet database engine is version: 4.00.8618.0

My co-worker is using:
Windows XP Professional (SP2)
Microsoft Office Access 2003 (11.6566.8132) SP2
Microsoft Jet database engine is version: 4.00.8618.0

-----------------------------------------

It would appear that it is a problem with SP3 of Access 2003, since
that is the only difference between my co-workers system and mine.
I've read some things that relate the issue to long filename. This is
something I can't avoid, because I'm importing the file that is
automatically generated with the naming convention, by a 3rd party
software provider. I also cannot rename this file and it's index
because then it yields a very different error about not knowing the
contents of the file.

My question is, what potential solutions can I work with here? This
is a process I need to conduct daily, with various different
databases, so difficult work around solutions aren't much of an
option. I've even be satisfied with downgrading to SP2 if possible,
I'd just need to know how to achieve that.

Any help that can be provided is most appreciated...

Thanks,

Brent

 

[John Nurick]

Hi Brent,

One thing I'd try is to give the import routine the short path
corresponding to the long one that it's choking on. This seemed to
work with older versoins. Here's a VBA function that takes a path and
returns the short version:


Function GetShortPath(ByVal FileSpec As String, _
Optional FailOnError As Boolean = False)
Dim fso As Object
Dim oFile As Object
Dim oFolder As Object
Dim S As String
Dim Buf As String

On Error GoTo ErrHandler:

Set fso = CreateObject("Scripting.FileSystemObject")
'Get a handle on the file
Set oFile = fso.GetFile(FileSpec)
Do
FileSpec = fso.GetParentFolderName(FileSpec)
If Len(FileSpec) = 0 Then Exit Do
Set oFolder = fso.GetFolder(FileSpec)
Buf = oFolder.ShortName & "\" & Buf
Loop

GetShortPath = oFile.Drive & Buf & oFile.ShortName
Exit Function

ErrHandler:
If FailOnError Then
Err.Raise Err.Number, "GetShortPath()", _
Err.Description & vbCrLf & "[In GetShortPath() function]", _
Err.HelpFile, Err.HelpContext
Else
Err.Clear
GetShortPath = ""
End If
End Function

 

[Pieter Wijnen]

Or The API version
Private Declare Function APIGetShortPath Lib "kernel32" Alias
"GetShortPathNameA" (ByVal lpszLongPath As String, ByVal lpszShortPath As
String, ByVal cchBuffer As Long) As Long

Public Function GetShortPath(ByVal LongName As String) As String
Dim ShortName As String * 256

APIGetShortPath LongName & VBA.vbNullChar, ShortName, VBA.Len(ShortName)
GetShortPath = VBA.Left(ShortName, VBA.InStr(ShortName, VBA.vbNullChar) -
1)
End Function

Pieter

Hi Brent,

One thing I'd try is to give the import routine the short path
corresponding to the long one that it's choking on. This seemed to
work with older versoins. Here's a VBA function that takes a path and
returns the short version:


Function GetShortPath(ByVal FileSpec As String, _
Optional FailOnError As Boolean = False)
Dim fso As Object
Dim oFile As Object
Dim oFolder As Object
Dim S As String
Dim Buf As String

On Error GoTo ErrHandler:

Set fso = CreateObject("Scripting.FileSystemObject")
'Get a handle on the file
Set oFile = fso.GetFile(FileSpec)
Do
FileSpec = fso.GetParentFolderName(FileSpec)
If Len(FileSpec) = 0 Then Exit Do
Set oFolder = fso.GetFolder(FileSpec)
Buf = oFolder.ShortName & "\" & Buf
Loop

GetShortPath = oFile.Drive & Buf & oFile.ShortName
Exit Function

ErrHandler:
If FailOnError Then
Err.Raise Err.Number, "GetShortPath()", _
Err.Description & vbCrLf & "[In GetShortPath() function]", _
Err.HelpFile, Err.HelpContext
Else
Err.Clear
GetShortPath = ""
End If
End Function

When attempting to import a .dbf file into MS Access 2003, I receive
an error message. My co-worker, with a similar setup, does not
receive this error. I only received this error after reinstalling my
computer after a hardware crash. I assume I wasn't completely patched
before, thus the reason I was able to use it successfully.

--------------------------------------
Error reads:
"The Microsoft Jet database engine could not find the object 'w300186-
RR.dbf'. Make sure the object exists and that you specify its name
and the path name correctly."
-----------------------------------------
I'm using:
Windows XP Professional (SP2)
Microsoft Office Access 2003 (11.8166.8172) SP3
Microsoft Jet database engine is version: 4.00.8618.0

My co-worker is using:
Windows XP Professional (SP2)
Microsoft Office Access 2003 (11.6566.8132) SP2
Microsoft Jet database engine is version: 4.00.8618.0

-----------------------------------------

It would appear that it is a problem with SP3 of Access 2003, since
that is the only difference between my co-workers system and mine.
I've read some things that relate the issue to long filename. This is
something I can't avoid, because I'm importing the file that is
automatically generated with the naming convention, by a 3rd party
software provider. I also cannot rename this file and it's index
because then it yields a very different error about not knowing the
contents of the file.

My question is, what potential solutions can I work with here? This
is a process I need to conduct daily, with various different
databases, so difficult work around solutions aren't much of an
option. I've even be satisfied with downgrading to SP2 if possible,
I'd just need to know how to achieve that.

Any help that can be provided is most appreciated...

Thanks,

Brent