Problems with Pdox 9 Using BDE 5.202 and Windows 2000 2

[Bystander]

Dear Colleagues,

A work we have recently moved to BDE 5.202 and a Windows 2000 desktop operating system. I now find that an application that runs smoothly in all other environments and machines using BDE 5.01 now takes nearly 60 seconds to open the main screen and as long as 2 minutes to get a print box up for reports. Queries also seem to take as long as 30 seconds even on small datasets. In the runtime version I also keep getting Unexpected General Protection Violations when I open up forms attached to lookup tables.

I am using paradox 9, all the tables have been set as Paradox 7,8,9 format, the language is ASCII, ANSI. There are only 2500 records with misc associated child records.

Can anyone advise what the solution might be.

Regards

Bystander

 

[footpad]

Bystander,

I waited before answering this, hoping someone who's using Paradox in the same environment would first chime in. I don't know why you're getting such slowdowns, however, I have a few guesses based on a little bit of prior experience.

Since everything works on some machines, but not others, I'm assuming there's something specific to the machine that's being troublesome. (I'm not sure it's the new BDE, though.) A lot depends on the local situation, of course. The behavior you've described is unusual. It should be solveable, especially since you're got other workstations that work more reasonably.

Based only on what you've described, I suspect your startup issue may be a network resource resolution issue. I've seen similar behavior from Windows itself when it tries to use or list resources for the first time. The delay seems to stem from Windows believing it needs to validate all network resources. When it finds one that isn't correct (e.g. a drive mapping pointing to an unavailable server), Windows waits a period of time before moving on with its list.

In addition, here's a random (meaning off the top of my head) list of things to check:

1. Make certain that BDE was installed by the Administrator, not the actual user. This is very important.

2. Verify that all installed printers are actually available and are also mapped to LPT ports instead of UNC paths. While Paradox does support UNC, I've seen cases where capturing the UNC to a printer port seems to make things easier to live with. I've not verified that rigorously, though, so your mileage may vary.

3. Similarly, make sure that drive containing the NET FILE directory is mapped to a drive letter instead of using a UNC.

4. Make sure you've disabled opportunistic locking and "new locking semantics." These are essentially lazy write caching and can cause integrity issues (more information and details can be found at

http://www.bdesupport.com/stability.htm).

5. Verify that the BDE32.CFG (or whatever) file on the troublesome machine is configured the same as the BDE32.CFG file from your BDE 5.01 machines. Check NET FILE, LOCAL SHARE, and other related settings.

6. Verify that you're using the right BDE on the troublesome workstation. The information is available through the BDE Administrator in Control, but it's not as obvious as you might think. (See

http://techtricks.com/paradox/bdeversion.php3

for details.)

7. If you're not using Microsoft Networking as your primary network client (e.g. you're using Novell or something else), then verify the version of the network client. This varies from vendor to vendor, but can usually be done through Control Panel. This can be very important for most network clients have been known to be problematic from time to time.

8. Also, if you are using Microsoft Networking as your network client, then verify that LOCAL SHARE is set to TRUE in every client's workstation. If you don't do this, then you will not be able to reliably share your tables.

9. Make sure the troublesome PC has plenty of free disk space and that the user's profile has full access to the directory currently set as the user's private directory in Paradox. (Remember, Win2K tries to be more intelligent about default user rights, though there is some disagreement about the success of its default choices.) Also, make sure that private directories are stored in the local hard drive, if at all possible.

Now, there is another possibility, one most people discount when I try to describe it to them, but one that I have found to be very important. Namely, style sheets. You probably don't use them directly, but Paradox always saves style sheet information with all forms and reports, so you actually do need to check this. Complete details can be found in a set of three articles on my web site (start with

http://techtricks.com/paradox/styleprobs.php3),

but the basic idea is fairly simple:

1. Open your main form in Design mode.

2. Choose Format | Style Sheet.

3. Check the name of the current style sheet. If you don't see one or you see one pointing to a drive/directory that doesn't exist on the workstation, then you've found at least part of your problem.

The fix is to resave the form (all forms and reports, actually) using a stylesheet stored on a drive available to all workstations that will use the documents. I generally use C:\, for that's the most common.

The problem affects all Paradox users that a) install Paradox on a drive other than C: and b) distribute forms and reports to other users. It surfaces when the other users try to open forms and reports when they do not have a drive letter on their machine that corresponds to the drive letter that Paradox was installed to on the developer's machine. I know; it's confusing. Here's an example:

1. I install Paradox to a second hard drive/partition mapped as drive D on my computer.
2. I build you a Paradox app and then give you a copy to install.
3. You install the application to your computer, which has a CD-ROM drive for Drive D:.
4. You start the application when you have a data CD in your CD-ROM drive. No problems.
5. The next day, you've got a music CD in your CD-ROM and then try to start the application. Problems.

While your computer has a drive D, it's not a valid data drive when you start Paradox and open your application's documents. Thus, the drive letter associated with the style sheet saved with all Paradox documents (forms and reports) is not valid. Thus, you run into problems. I've seen three types of problems associated with this issue:

a) Slowdowns trying to open documents.
b) Random GPV's opening or closing documents.
c) Random GPV's trying to set/change filters or ranges on documents.
d) Problems saving documents ("An error has occurred. Please save your documents now.&quot

In my experience, the fix is to move the Paradox stylesheets to the C: drive and then resave all documents. Specific steps (and a simple script) are available on the web site.

Again, I don't know if you're dealing with a stylesheet issue or something else.

Still, I hope this helps...

-- Lance

 

[Bystander]

Footpad,

May I firstly say thank you ever so much for taking the time to think through my problem in such detail. The style sheet issue seems very promising because I do remember havng to install Paradox on a D drive partition because the C Drive was full. I also did some of the work using a laptop with Paradox installed on a C drive but working from a D drive partion where windows XP was installed and booting Paradox from XP.

I have found a potential work around in as much as I can send reports directly to the printer e.g "rpt.rint" rather than "rpt.open" prior to printing. I also had to revert to issuing everyone concerned with a full version of Pdox9 rather than the Runtime. This stopped the GPVs but I need to work through your possibilities as I cannot afford to have the same thing keep happening in future. The BDE seemed a little odd as well, it would sufficx long field names >8 characters with part of the table name during mail merges.

Many thanks again form the advice.

Bystander