Results 1 to 10 of 10
  1. #1
    Lounger
    Join Date
    Apr 2001
    Location
    Herlong, CA
    Posts
    26
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Unable to Import .dbf Files to A2k

    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?

  2. #2
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Unable to Import .dbf Files to A2k

    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.
    Charlotte

  3. #3
    Lounger
    Join Date
    Apr 2001
    Location
    Herlong, CA
    Posts
    26
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Unable to Import .dbf Files to A2k

    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.

  4. #4
    PatriciaWilliams
    Guest

    Re: Unable to Import .dbf Files to A2k

    > 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.

    StoneMan,
    ......The question just jumped in my mind upon reading your messages -- does the other developer that you refer to above have Win 95 or Win 98 -- not that I think that's the problem, but might look at everything.
    ..... (That's all the input I can give -- I think these sorts of problems are the most difficult, sometimes.)
    thx
    Pat

  5. #5
    Lounger
    Join Date
    Apr 2001
    Location
    Herlong, CA
    Posts
    26
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Unable to Import .dbf Files to A2k

    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

  6. #6
    4 Star Lounger
    Join Date
    Dec 2000
    Location
    London, Ontario, Canada
    Posts
    437
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Unable to Import .dbf Files to A2k

    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. <img src=/S/grin.gif border=0 alt=grin width=15 height=15>

  7. #7
    Lounger
    Join Date
    Apr 2001
    Location
    Herlong, CA
    Posts
    26
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Unable to Import .dbf Files to A2k

    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.

  8. #8
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Unable to Import .dbf Files to A2k

    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.
    Charlotte

  9. #9
    4 Star Lounger
    Join Date
    Dec 2000
    Location
    London, Ontario, Canada
    Posts
    437
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Unable to Import .dbf Files to A2k

    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. <img src=/S/grin.gif border=0 alt=grin width=15 height=15>

  10. #10
    Lounger
    Join Date
    Apr 2001
    Location
    Herlong, CA
    Posts
    26
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Unable to Import .dbf Files to A2k

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •