|
Post by Jos on Jan 30, 2024 0:30:21 GMT 1
To start: "#" isn’t recognized, so will produce a “Bad command or file name”. Use "rem", or ":" (designating a label).
Remove the "KEYB GR 850", that’s redundant/useless. The logged "CodePage: 850" (and the keyboard layout) comes from the Windows settings. You can eventually change the codepage by CHCP <codepage_number>. But that is for exceptional circumstances only since it will be already correct.
As a program is started, Windows sets the current work directory (CWD) of that instance to the directory of the program. DOS requires at least one drive letter (the boot drive). By default vDos assigns it as C: to the CWD Windows set.
Jos
|
|
|
Post by herman on Jan 30, 2024 10:57:03 GMT 1
Hai,
The only thing I know is that you must for a good working on a network is a knowing issue in the past that on a Windows envoirement do
SET AUTOSAVE ON and SET SAFETY ON
Greeting Herman
dBase 5.0xx58 user
|
|
|
Post by herman on Jan 30, 2024 11:06:08 GMT 1
There are other issues in dBase 4 (witch for now, I don't know) witch is not in dBase 5.0xx58
There is another reason to do a upgrade.
dBase 5 is relevant stabler and faster
There are two versions of 5 Use de xx58 latest version
The only thing you must do is
SET LDCHECK ON
And append your data in a new dBase 5 file
The rest is 100% compatible
Herman
|
|
|
Post by Jos on Jan 30, 2024 12:36:11 GMT 1
I found two settings relevant to the issue:
SET AUTOSAVE on/OFF Saves any changes made to database files as they are made. Safeguards against loss of files due to power or hardware failure. When SET AUTOSAVE is OFF, dBASE saves records to disk as the record buffer is filled.
This implies dBase would cache with AUTOSAVE OFF, no matter what?
SET LOCK ON/off Determines whether a lock is applied to records in a multi-user system. Files and records in use are automatically locked when you use any update or edit command.
And locks records with LOCK ON, hopefully also index pages. Though what does "in a multi-user system" mean. dBase will only apply locking if it determines the PC is in a multi-user system?
Jos
|
|
|
Post by scotx on Jan 30, 2024 23:25:01 GMT 1
Hi Jos,
we performed two sets of tests with our application today.
Test Set 1
Setup - vdos 24.x.x from the 29.01.2024 - Windows mapped via UNC - Application with a built in 1 second delay Test - 3 parallel sessions of the application running the function that performs 100 append from array action including verification check - 2 additional sessions with users manually performing
Result Not one single record was lost
Test Set 2
Setup - vdos 23.x.x from the 28.05.2023 - Windows mapped via UNC - Application with a built in 1 second delay
Test - 3 parallel sessions of the application running the function that performs 100 append from array action including verification check - 2 additional sessions with users manually performing
Result Not one single record was lost
Quintissense We are not sure at the moment if the mapping of the dbase application per UNC would have been enough to solve the issue, if caching was the problem. Discussions are taking place as to whether the synthetic delay should be removed and the tests repeated. Will write again in the forum.
Thanks very much for your support Jos
|
|
|
Post by Jos on Jan 31, 2024 8:13:15 GMT 1
Mapping by UNC’s or Windows drive letters isn’t noticeable by dBase, it gets only DOS drive letters presented. USE T: T:\ is just ambiguous, in contrast to USE T: \\server\share_name\.
I suggest you remove the delays, eventually even (largely) raise the number of records to add. So to further stress the testing conditions. It’s a nightmare to envision such a mishap would happen in a production setting. Now you trap that immediately, under live conditions perhaps after weeks. Fixing it or a recent backup wouldn’t help out; meanwhile many logical errors (incorrect data) based on a single faulty record could have accumulated. Losing all work by restoring a backup of weeks before is neither a pratical option…
Jos
|
|
|
Post by scotx on Feb 2, 2024 15:43:51 GMT 1
Hi Jos,
just an update. Our problem still exists. We have a strange scenario that, when appending the many records to the table, that we have cases where the recno, that is recorded after a successful append and therefore should always increase, jumps backwards!!! Meaning already written records are being overwritten! Still trying to build the test tool that can reproduce the case.
Scot-X
|
|
|
Post by scotx on Feb 4, 2024 9:12:25 GMT 1
There are other issues in dBase 4 (witch for now, I don't know) witch is not in dBase 5.0xx58 There is another reason to do a upgrade. dBase 5 is relevant stabler and faster There are two versions of 5 Use de xx58 latest version The only thing you must do is SET LDCHECK ON JH: Thanks Herman, the LDCHECK parameter is new to me. I'll take that up in the dBase V test environment before we do any further tests
And append your data in a new dBase 5 file The rest is 100% compatible Herman
|
|