INSTALLING DBASE ON XP

[mkyin2003]

Hi i was wondering if anyone could possibly help me.
I have recently installed Win XP and am trying to install dbase4 onto xp.

I've been able to install dbase but it keeps on giving me an error, which is:-

Error #530 Mismatch Language Driver For Database: Service.DBF
Error opening OPENFILE.QBE

What do i do to rectify this problem???

 

[DavidSLee]

Hey mkyin2003,

The popular theory is that newer versions of Windows only have a bare-bones DOS. Worse still, the faster the processor the more errors dBASE-IV will throw at you. I know, I've been there and got the tee shirt. Browse through this forum and you'll find more programmers with the same problem - including me!

Regards,
David Lee

 

[BrainB]

Yes David.
Didn't they supply a patch to slow down the processor to get DBase to work ?

Regards
BrianB
** Let us know if you get something that works !
================================

 

[dbMark]

See thread290-1056644 for additional details. Likely you installed dBase IV 2.0 or later which allows more than one code page. Earlier versions only had one, which is now known as code page 437 (ASCII).

Error 530 is when the mismatch is found with databases.
Error 531 is when the mismatch is found with indexes.

Read the manual about SET LDCHECK. Most likely you are using the default setting of SET LDCHECK ON which is fine. Even if you have the same DOS code pages set on both computers, you need to have LangTable and ASCIIsort set identically for all tables or you can encounter this conflict. Probably the dBase booklet Getting Started discusses how to set the code page correctly. Your problem may be that these tables do not match the current settings. Probably your earlier dBase version was limited to code page 437, but now you're trying to use another code page? You'll have to standardize on one or the other, most likely.

Note: A table is permanently marked for a certain code page. You'll have to create new tables and append from the old ones to change code pages. But beware of character differences since they are not automatically converted when appended. Test and check afterwards to be sure!

Generally I find that I use the default code page 437, as that's the most common for ASCII order. Another common one is 850. (Each code page number has its own driver.)

dbMark

 

[karmic]

I installed dbase4 on windows 2003 server about a year ago, dual 3.0 gig xeons, all xp clients and I didn't have any issues at all with timing...

The difference is I cut it over from novell 5, had to learn the programming on the fly but it works like a charm now.

The one thing you may want to look at tho is opportunistic file locking, I had to turn it off with xp. (turn it off with pretty much any dos based database)

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q296264

Other than that, I can't remember much about the cutover, I did a braindump after that nightmare.

~ K.I.S.S - Don't make it any more complex than it has to be ~

 

[willyw]

I am about to migrate a large dbase 5 system from Novell to XP. I've tested it and it seems to be OK. Does anyone know of anything that might go wrong, apart from SCAN?

I note karmic's comment about disabling opportunistic locking. I'd like to ask him or anyone else whether this means that data written to a table could be overwritten by a second user, i.e. does disabling mean losing the safeguard aganist this?

 

[karmic]

Have you connected with more than one machine??? I thought it worked too but I got bitten in the butt big time. The way dbase was installed on the novell server forced me to set up a dfs root on the 2003 server to get it running properly. If you have it working already without too much hassle, congrats

As for the oplocks, it does remove some of the safeguards... It's been over a year since I cut dbase over now, and there hasn't been any problems with the database to date. They have a maximum of 25 pc's accessing at any given time and there's never been issues.

I have another cutover in about 6 months so if you have any tricks that you used to make life easier, please post them

~ K.I.S.S - Don't make it any more complex than it has to be ~

 

[dbMark]

Hmm, we've left the original topic, haven't we?

Yes, SCAN has become unreliable when dBase is run the Windows NT family. See thread290-882126 which describes how dBase SCAN on Win 2000 and XP can fail. This thread also describes issues with FOUND() and stand-alone NDX indexes which can be unreliable.

In the Netware environment ID() returns the user name.
In the Windows environment ID() returns the computer name.
I think in both cases the string returns with a number tacked onto the end to differentiate sessions. Since I seldom have dBase running in 2 instances on my computer, I usually see only "1" added.

On the other hand, highly regarded FoxPro for DOS has also had problems over the years. It had to have a patch long ago in order for it to work with CPUs running faster than 300 MHz. My guess is that patch just set some timer 10 times higher, because some users upgrading to 3 GHz CPUs started compaining recently.

Apparently none of us little guys (programmers and end users) are allowed to see the underlying database language code so we could see what went wrong and where and how to fix it. Kind of scary when you can't trust a command or a function 100% of the time. When it comes to legacy software, none are exempt from "issues".

dbMark

 

[willyw]

Thank you, karmic and dbMark, for responding. Yes, I've run it on 2 machines coming off a Windows 2003 server. There are 16 machines in all. Karmic, what happened that forced you to set up a dfs root (so that I can look out for it)? btw, I stopped using SCAN under Novell because of unreliability.

 

[karmic]

hrmmm... If I recall, I needed the ability to "map root" on the 2003 server, the same as the map root on the novell server.

Dbase was programmed with the full data paths, so using the UNC connection of \\server\dbase wouldn't work. The data paths were sometimes 6 layers deep like \\server\dir1\dir2\dir3\dbase... T'was a real pain.

It was easier in my case to run a dfs instead of changing all the prg files manually. The biggest thing I can tell you is to watch your paths. I know I had a problem running the admin program after the cutover, can't remember why tho.

Keep in mind that I may have taken the long way around the bush, it was the first time I had ever had any dealings with Dbase. It was a fun challenge and I had one night to make the cutover.
If you have an easier way, please post it

~ K.I.S.S - Don't make it any more complex than it has to be ~

 

[karmic]

k, I just read my old post from a year ago and I also had problems with dbase versions. The program had been updated a few times but the old versions were not removed. Once I found the right version, dbase started working.

Still had to use the dfs tho...

Good luck

~ K.I.S.S - Don't make it any more complex than it has to be ~

 

[dbMark]

We tried to run Windows XP with Novell 5.0 but the drivers were a bit touchy so we never really implemented that. Later with Windows 2000 Server and mixed WinMe and WinXP workstations, I noticed XP aborting scans prematurely. With the same code I used to force SCAN/ENDSCAN to fail on a Windows XP computer with file-in-use errors, it did not fail with Windows Millennium. That's why I think the SCAN issue is limited to the Windows NT family or perhaps just XP.

Either way you look at it, there are too many XP computers out there to use SCAN everywhere. In SCAN loops where no enclosed code is going to try to open tables in a shared environment within those loops, you're probably safe.