Migration from Novell5x client/Windows 2k to strictly Windows 2k

[misman2973]

Good Afternoon Everyone,
Here's the delimma: I'm running a Paradox7 Complaint handling app loaded on 8 clients with the backend running off a Novell Server tied to a Windows 2k Server(at startup the clients login to Novell and Windows separately). Last week we decided to migrate the Paradox7 app over to strictly the Windows 2k Server environment.
After migration we encountered numerous issues such as:

(5) of the big tables lost their indexes and had to be rebuilt and reindexed.

Objects all throughout the application would not open specifically a BLOB file type related table.

The app would work fine with one user but when we went full boar with everyone the .lck files couldnt lock down a file quick enough and we were getting all sorts of file sharing errors. We were as well getting couldnt open "object" errors. For example, "error was triggered in the 'open' method on an object of the tcurser type", was a very frequent error.

I went through the process of verifying the table and then I would either rebuild or restructure from there. After we thought everything was sound we would get "Index is out of date" again just after fixing what the tools stated was wrong. I even axed the .px files before reindexing so I could have a clean restructure and/or rebuild.

ANyway, the reason we got away from Novell was because of Win2k security improvements and to ramp up the throughput for the 8 clents accessing the Paradox7 app. All in all, the app was faster with the pure windows environment but more errors came about. After getting lame support for our situation we decided to revert back to the old setup of having a Novell5x shell on the clients with the DB located on the Novell server and the Windows 2k server os running parallel.

Conclusion: The errors started to occur when the DB was moved from Novell to strictly Windows. It worked fine in it's previous environment.

Questions:
Could my issues be OS driver related?

Could the speed of the network hinder application performance and cause lock errors considering our clients have the minimal hardware reqs?

Could there be issues with the Novell Native drivers leaving some sort of imprint on the Paradox7 app?

Has anyone heard of the default Win2k driver MDAC 2.5 not being compatible with PAradox apps? Jet 3.51+?

Is Paradox7 not dynamic enough to recognize a new OS environment?

Any reccomendations would be greatly appreciated!
Thanks and have a great day.

CG

 

[footpad]

Let me start by answering your direct questions and then I'll offer some tips and ideas for you to think about:

>> Could my issues be OS driver related?

Possibly, though they're more likely related to configuration issues.

>> Could the speed of the network hinder application performance and cause lock errors considering our clients have the minimal hardware reqs?

Possibly, though--again--your issues can most likely be resolved through confugration changes.

>> Could there be issues with the Novell Native drivers leaving some sort of imprint on the Paradox7 app?

No. Paradox has long used standard API's for network communication.

>> Has anyone heard of the default Win2k driver MDAC 2.5 not being compatible with PAradox apps? Jet 3.51+?

While Paradox can connect to ODBC data sources, it doesn't use MDAC to communicate with the underlying database--unless you've specifically created an ODBC DSN. Instead, Paradox uses the Borland Database Engine (BDE) and I'll bet many of your problems stem from changes that need to be done in your BDE.CFG file (more than that in a moment).

>> Is Paradox7 not dynamic enough to recognize a new OS environment?

While it may be necessary to set the Application Compatibility setting for Paradox 7, it runs fine under Win 2K.

As far as the errors you're getting, many are general errors. For example:

-- Cannot open object errors usually appear when there's a design assumption that's no longer valid. For example, you might have some code that tries to open a resource that's no longer where it once was.

-- Cannot open TCursor errors are similar, though they're specifically related to tables. Some code tried to open a table in memory, but (for whatever reason) wasn't able to do so.

-- Index out of date errors appear when the index file no longer exists or has become damaged. When this happens on a regular basis, it suggests either communication problems or configuration problems.

In general, Paradox tries to provide specific information when it displays errors, though it does so in a somewhat obscure fashion. There's a >> button that's enabled when more information is avialable and that additional information is usually more specific than the initial error message. Be sure to click >> whenever possible.

Based on your description, it looks like you need to verify that:

-- Your Windows 2000 server is optimally configured for Paradox/BDE. See

http://www.thedbcommunity.com/faq/29.htm

for the main highlights. While the FAQ was originally written for Windows NT, it applies to Windows 2000 and XP. Additional information can be found at

http://bdesupport.com/stability.htm,

though their pages are written from a Delphi/C++ Builder perspecitive.

-- You probably have one or more database aliases defined in BDE Administrator *and* I suspect these point to the wrong locations. (Note: Since you're using Paradox 7, be sure to map your Win2K server to drives; do not use UNC conventions to locate data. Paradox 7 had problems with UNC, though these were resolved in later versions of Paradox.) To check your database aliases, use the BDE Administrator in Control Panel. And, yes, BDE must be available to all users.

-- You may also need to verify that BDE is properly configured for network access. See

http://www.thedbcommunity.com/faq/13.htm

for details.

-- Finally, if your users will be running Paradox 7 under Windows 2000 or XP, you may need to set the Application Compatibility properties. See

http://techtricks.com/paradox/sharedmem.php

for more information.

While this seems like a lot of work, I suspect that a few key changes will resolve your problems. Unfortunately, it's hard to say precisely which changes are needed and that's why I've tried to point you toward useful information sources instead of searching for the silver bullet.

Hope this helps...

-- Lance

 

[misman2973]

Lance,
Thanks for pointing me in the right direction, I'll let you know how it turns out.
CG

 

[edunaway]

When we made this move, it was with Paradox 9.

One of the things that happened during the move was a complete change of drive letters. We could still open the table but all the supporting files were allegedly corrupted (secondary indexes etc). What we found was that the paths for those files were hardcoded so we used the enumFieldStruct method to get that info into a table, made the necessarily path changes and then used CREATE to correct the pointers.

We also had to make sure that everyone's settings were pointing to the pdoxnet directory on the network.

 

[misman2973]

Lance,
Just wanted to say thanks for all the info concerning my question. We've tested everything with the new configuration changes and it works like a charm.
Chris

 

[footpad]

Chris,

Glad to hear it; thanks fo rletting me know.

-- Lance