Page 1 of 2 12 LastLast
Results 1 to 15 of 19
  1. #1
    Join Date
    Jun 2005
    Posts
    36

    Question Unanswered: error 3043 disk or network error...help

    Hi, a have a program that for the past 3 years has worked with no problems. Last week I created a small 3 workstation network, 1 connected directly to the 2Wire router and the other 2 wireless and set up my program to run on the front workstation which the programs resides. Created a network drive that points to the folder where the program is and execute an instance of the program. Now while trying to update the data base from the back workstation I keep getting this error after a few updates. I have done some research and found the the cause could be nics drivers, (latest installed) other posts mention the temp variable (done Temp=C:\Temp; Tmp=c:\Temp) with a temp on drive C. but still get this error. Any suggestions?

    Your help would be greatly apreciated.

    1 Frontworkstation windows XP(sp3) Access 2003(sp3)
    2 Backworkstation windows 2000(sp4) Access 2003(SP3)
    3 Backworkstation windows xp(sp3) Access 2003(sp3)

  2. #2
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Sounds like a networking issue to me. Bad connection? I only ever get this message when a database is running from a server and some twaddlenut goes and turns off the server.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  3. #3
    Join Date
    Jun 2007
    Location
    Maitland NSW,Australia
    Posts
    388
    It is a network connection problem and sometimes happens when you loose a network connection when you are designing forms etc.

    You save the form assuming all is ok. When you open the form a Network error is displayed.To fix this you will need to create a blank database then import from the old database and during the import look at the objects imported, an error will be displayed and it will be caused by one the last objects imported.

  4. #4
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Note that it only takes one second of downtime... once the network connection is lost, restoring the connection again doesn't stop this message from appearing endlessly until you End Task and restart it. I believe the same thing happens to at least some versions of Outlook.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  5. #5
    Join Date
    Jun 2005
    Posts
    36
    Thanks for the reply guys. I think this is a hardware problem and not Access or a form as I cannot duplicate the problem on my home network with the same program.
    Out of the 3 pc's I have on the netowrk 2 have brand new wireless nics (linksys) and the other one where the program resides has a build-in nic connected via ethernet to the router, it's a 5 year old pc, my next step will be to disable via bios the onboard nic and replace it with a linsys new one ans see what happens. The router is a 2wire which I will raplace with a WRT54G by linksys if the problem persists.

    Anyway, thanks for your comments.
    regards

  6. #6
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    I'm sure you're on the right track now!
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  7. #7
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Poppa Smurf has a good point. I try to design mdb's over a stable network as a hiccup in the network can be disasterous when it comes to corrupting MSAccess forms when designing them. Once the form is corrupt, you'll have to import into a new mdb or use the /decompile or jetutil utility to fix. It's easier to simply work on a good network (or even the local drive) versus sometimes spending hours trying to fix a corrupt form (or module).
    Last edited by pkstormy; 05-27-09 at 23:06.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    I almost exclusively make design changes on local drives.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    if you are intending on using a local drive for temporary files then examine the environ variables.. they should tell you the physical address of the temp file, or designate your own temp space.. I still keep finding systems with directories called gash, againt he environ variable should be able to tell you the system drive
    I'd rather be riding on the Tiger 800 or the Norton

  10. #10
    Join Date
    Jun 2005
    Posts
    36
    Just like StarTrekker, I also do my programming/desing on local network.

  11. #11
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Local network (LAN) or local disks (HDD)? I do my best not to use networks at all when designing. Sometimes it's unavoidable, but yeah, I have lost enough time to failing networks to be wanting to dodge the bullet.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  12. #12
    Join Date
    Jun 2005
    Posts
    36
    oopppppssss, I ment to say local HDD...lol

  13. #13
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    The only thing I found difficult when working on a local drive is that...

    1. That drive is usually not backed up on the network system (contact the network admins to have your work's local drive added to their backup system if they are able to do it.)

    2. When you're working from home/somewhere else and connect in via web/citrix/terminal server/vpn/etc.. to your work place, you probably won't have access to your work's local c: drive. I will usually remote desktop connect into my local drive once I've connected into the work system. Note that some work places may frown on users remote connecting into their local c: drive at work (or may not even have that option available.)

    Otherwise, it can somtimes be a pain copying your mdb from your work's local computer to a usb key/network and then copy it from there to whatever computer's local drive where you want to continue working on the mdb.

    But working on a local drive can be a blessing if the network is unstable. (as a last note: if you don't have a fast connection to your work's system, working on an mdb over a slow connection to your work site is very risky!) For example, your work has a blazing fast network system but you connect into it via a slow dial-up service - very risky for developing in this kind of environment (and possibly time to re-consider your home's dial-up service to cable or DSL.)

    Everytime before I open an mdb to make any changes, I simply do a copy/paste of the mdb before opening it. For the 2-3 seconds it takes to do that, there's really no excuse for not having your own backup should something go wrong in the mdb. DON'T rely on your work's backup system as you can easily lose a day's worth of work should your mdb become corrupt at the end of the day and you need to contact the network guys to restore your backup from the previous day. (after all, those 2-3 seconds to make a backup copy of the mdb can save you HOURS and HOURS of work!!) Make your own backups often!! (unless of course you're working on an old, old, old, old computer which only has a 20 gig hd and you need to consolidate space - even then....)
    Last edited by pkstormy; 05-29-09 at 14:26.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  14. #14
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    As a last note,

    Should your mdb become corrupt and you start cursing Microsoft, just remember that there are a lot worse products out there to develop code in which are a lot less forgiving when a problem happens! I personally find MSAccess to be the most forgiving for any mistakes in coding. - but us developers never make mistakes - right.
    Last edited by pkstormy; 05-29-09 at 14:39.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  15. #15
    Join Date
    Jun 2005
    Posts
    36
    So true PK, I also like MSAccess very much and yes it is very forgiving and if you let your creativity go wild, you can come up with great apps.

Posting Permissions

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