Unable to Import .dbf Files to A2k

Topic

New Reply

Last week at work (U.S. Army Supply Depot) my MSOffice Suite97 was upgraded to Office2k and now I cannot import DbaseIII files to my new Access2k program. I get one of those famous cryptic error messages: “Invalid characters
or too many characters used in the file name.” (I am well aware of the old DOS 8 character rule for DBase as is our Computer Center) Previously with Access97, .dbf files imported like a bullet.

All of my Access .mdb files use data which is scanned
by our Computer Center from our Main Frame back east from a
1960’s era Cobol system. This monster Main Frame system collects all of the data from our Depot as well as a host of other Depots which are also on the System. I request the particular data that I need from the Main Frame and the Computer Center pulls that data down from the Main Frame and puts it out on our LAN in .dbf files for me to import. So I was very upset that that my new Access2k program will not import these .dbf files.

I remembered posts on your Access Board about similar import
problems and searched the posts out and tried the remedies
suggested but to no avail, nada, nothing helped.

I first tried various new file names for the .dbf files.
Nothing, same cryptic error message.

I tried a suggested remedy of creating a new Access2k database shell and them copying all objects from the old .mdb file. Nothing, same result.

Then I tried another suggested remedy, downloading Jet 4.0
SP5 (Service Patch 5) from Redmond. Nothing, same result.

At this point, I was really baffled because at home I have
my own Access2k program which I use to work on Hot Projects
from work on weekends. My Access2k program at home imports
the .dbf files like bullets just as Access97 used to do at work.

Now I feel a terrific transparent disconnect with the people
in Redmond. Actually, I am beginning to think that there are no real programming people up there but only a couple of
massive supercomputers in parallel and the programmers are
virtual people.

I know I am getting pretty old but this is ridiculous; my mind is still sharp or is it?

The only thing I can think of now is to get BDE (Borland
Database Engine) and try it.

Charlotte, do you have any ideas?

Does anyone out there see any solutions?

Reply | Quote

Replies

The fact that it works at home means it isn’t Access but your installation that has a problem, so you can’t really blame people hundreds or thousands of miles away for not being able to fix it for you. The BDE is only needed if you want to write to the files but shouldn’t be necessary to read them. Were the ODBC drivers for dBase installed on your work machine when they upgraded it? Make sure the dbase ODBC drivers are installed, and try a detect and repair from the Access Help menu. I’ve had that cure some pretty strange stuff in Access 2000, and it can’t hurt.

Are you using the same version of Windows on both machines? Are you trying to import the same files from the same paths on both machines? Are you trying to import them across the internet, from a network drive, or locally? Are you using mapped drives, local drives, UNC paths or what?

The error message means what it says–there’s something in the path that it doesn’t like, so try to track that down whatever else you may do. Troubleshooting is a process of figuring out what is different between what works and what doesn’t and then determining why.

Reply | Quote

Charlotte, Thank you very much for your post.

First, I need to apologize to the folks in Redmond. It is kind of a kneejerk reaction to blame Microsoft for all computer problems and I’m sorry.

OK, let’s see.

Computer at home:
MS Win95 (4.00.950A) & Access 2000 (9.0.3821 SR-1)

Computer at work:
MS Win98 SE (4.10.222A) & Access 2000 (9.0.3821 SR-1)

So, different OS but same Access.

The .dbf files are loaded to the Hard Drives (C:) on both machines then touched by Access to import them. I get the .dbf files in the original instance off our Fiber Optic
LAN System (Novell NetWare System) then copy them over to
my Hard Drive. To work on the .dbf files at home I copy
the files to 3.5″ Diskettes or 100MB Zip Disk
and then copy them to my Hard Drive at home before importing. So the path for Access is short and simple
to my local hard drives.

I have the same ODBC Drivers for dBase and FoxPro on both machines.

Next, I called the other serious Access Developer on the Depot to see if he has had the same problem. He also imports .dbf files from our Computer Center
to get some of his data and he got the same upgrade to Office 2000 as I did. He reported no problems at all with importing the .dbf files.

At this point that leaves the A2k Detect and Repair.
I tried that but it requires the Office 2000 Installation Software to proceed and that is kept locked up in our
Computer Center. So I put in a work order to have a Tech come out to the Mission Operations HQ where I’m located
and bring the Software.

It looks like the problem is in my A2k program itself so there seems to be a strong indication that Detect and
Repair will fix it. Will keep the Access Board
informed in case this happens to someone else.

Thank you again Charlotte for getting me going in one
direction.

Reply | Quote

Thanx for the post, Pat

My compatriot, the other Access Developer at the Depot,
does have the same OS as I do, i.e. Win98 SE. So it all
still points directly to the A2k program on my machine
at work.

The Division Chief of our Computer Center, who is a
totally excellent expert Visual FoxPro programmer sent
over his best Computer Tech this afternoon with the
installation software and we ran the A2k Detect and
Repair utility. The utility ran fine but had no effect
on the import problem. We looked closely at the ODBC
drivers on my machine and found a work around for the
problem. This routine involves changing the File Data
Type on import from “dBaseIII (*.dbf)” to
“ODBC Databases()” and then when the Select Data Source
box comes up to select the ODBC Driver we tried them all
but it would only work with the Visual FoxPro driver.
But this did import the .dbf File right into the A2k
database. The Tech also suggested trying an old faithful
routine of using Excel to open the .dbf File and saving
it in an .xls File and then importing the Excel File to A2k.
That also worked fine.

But I still am left with the question of why my A2k
program will not just directly import the .dbf File
as the other A2k programs do. The Tech is leaning
toward a Registry problem with the dBase driver part
of the A2k program and will be coming back out on
Monday and we will reload my A2k program.

So, I now have a work around but the basic problem still
remains.

Thanx again for your input. We’ll get this solved soon
I think.
back

Reply | Quote

Not really related to your problem but a possible solution to having to requisition your software everytime you need to run repair/install. While you have the install CD(s), and if you have the disk space .. copy the entire CD down to a flat file. Next time you need to run a repair, or add an option you can refer the install program to the flat file folder as opposed to the CD. No more requistions, no more waiting, what the heck save a tree.

Reply | Quote

Brian, I hadn’t heard of a routine like saving an
installation CD down to a flatfile and then using
the flatfile to do installation. Wouldn’t Microsoft’s
protection mechanisms prevent you from doing anything
with the code in the flatfile especially an actual
installation. It’s an interesting concept but if it
works it could put the bootleggers back in business.

Reply | Quote

It’s essentially what you do when you create an administrative setup for network installations. You can, in fact, copy the CD to a harddrive and use it from there, since you have the right to make a backup copy of the CD, at least in the current versions. That may very well go up the spout in the next version, of course.

Reply | Quote

The same security restrictions apply, that is to say if you do a fresh install to a new machine on the network, you will be asked for the CD Key. But for upgrading/adding to existing installations, it works the same regardless of whether the software is on a CD or a HardDrive. We use this method all the time and I only need to get up and walk to the Network Administrators office two offices down. I could probably use the exercise but, what the heck I admit it, I’m lazy.

Reply | Quote

Thanx Brain (oops, I guess you’ve come across this before. I did a typo on your name but it’s appropo for you, although Brian sounds nicer)

Anyway, Brian

Thanx for the info on the flatfile routine for program software management. Charlotte sent me an email too explaining about this (she is one sharp person). I checked
with our Computer Center ISSO (Installation Software Security Officer) and he agreed this routine does work and is legal under the particular licensing of the original software but we in DOD (Dept of Defense) are not allowed to
do it with software purchased by the Army. But I’m going to
try it a home just to see it work (with my own software).
In the old days everyone with a computer kept the software
which was loaded on his computer at his desk. Then eventually DOD got immense pressure from the big (and little) software manufacturers to get this under control because there was wholesale borrowing (for keeps) of government software. So, DOD set up the ISSO system we have
now which keeps software locked up at the Computer Center.
It did stop the unauthorized “borrowing” of software.

I guess I’ll sign off on this thread now. Currently, I’m
waiting on our Computer Center to come out and reload my
A2k and they might have to reload the whole Office2k to do
that (but I hope not). Am, getting along with importing
dBase files by opening them in Excel and saving as .xls files then importing them to A2k. That is the best work
around for the problem until we get my A2k program fixed back up.

Reply | Quote