I have a VB 6 Service Pack 5 Application that works with FoxPro 2.6 free tables. I use DAO 3.5 to open most tables, but on several forms I use the intrinsic data control because I need to display the data in a dbgrid. I set the databasename, connect, recordsource and recordsettype properties in the form_load event, then in the form_activate event I refresh the data control and assign an index to the recordset. This form is used for browsing and deleting only (via command buttons). When I add or edit a record, I open a second form and create an array of dao recordsets. I set the first recordset to that of the data control from the first form, then I use dao to open up to 2 more recordsets. When the user clicks on a "Save" button, changes are made to the first recordset, and may or not be made to the second and third recordsets. If a record locking situation occurs, the edits or addnews are canceled.
This all works fine at home and I never get any problems. When I install the application at the job site, I almost always get "Object or With Block not set" or "No current Record" errors. As these errors occur, the FoxPro 2.6 indexes become corrupt, and it would be unacceptable to have to reindex all files after each and every addition. I have error logging statements in each and every procedure, function, or event to track date, time, user, machine, error number, error description, routine name, and misc info.
Here are my perceived differences between home and the job site:
1. Job site computers are much faster than my home machine. My development machine is a Cyrix Pentium 200 running Windows 98 SE and my server is an Intel Pentium II 350 running Windows 2000 SP2. The job site has Pentium II 350's and Pentium 4 1600's running either 98, 98 SE, or Windows 2000 SP2, and the server is a Pentium III 800 running Windows 2000.
2. My home network uses a 5 port LinkSys 10/100 hub that is 2 years old but seldom used. The Job site has a 3Com 12 Port 10/100 hub that has been REMANUFACTURED and not all of the computers can connect at 100, most connect at 10. The job site also has a router connecting them to a DSL line, and the connection frequently drops. Powers that be assure me that although the hub has been remanufactured, it works just fine, and the slower connections are probably attributed to cabling problems.
3. At this point in time due to very small budgets, it is not possible to switch from a peer-to-peer network to client-server network.
4. The database files need to remain in FoxPro 2.6 due to Report Writer compatability, plus, if my new system crashes, they need to be able to start up the old system ASAP.
My questions are as follows:
1. Are these errors due to the legacy database? - One of the reasons for my new application is that the indexes on the tables keep getting corrupted. The second reason for the new application is to increase speed.
2. If I converted the FoxPro 2.6 tables to FoxPro 3.0 free tables, would this improve my situation? (I believe the Report Writer works with FoxPro 3.0)
3. Could the faster machines affect writing changes? Do I need to put a delay after Editing or Adding via a timer or dbengine statement?
4. Could the REMANUFACTURED hub, malfunctioning Router, or bad wiring be causing the program to lose the connection with the database or corrupting the indexes? - They frequently get garbage ascii characters in textboxes of memo fields.
Any and all help would be greatly appreciated.