Hi Marcos,
My thoughts reflect Ed's exactly... to go one step further, because DP.EXE
and DP.SYS have such miniscule footprints in both size and network traffic
loading them, I always place all files including these executables in common
location.
However that said, I expect you will say that the files are all in the one
location. If so, almost certainly the problem will relate to your
workstation (or server) configuration, which includes the dreaded SHARE.COM
Hopefully there are not other compelling reasons to have SHARE.COM loaded,
however my first suggestion would be to rem it out and then see how DP
performs. Once you have confirmed SHARE.COM as the culprit then look at why
it has been loaded. If it was just done as the standard configuration then
it might be safe to remove it, permanently but if it was placed there for
another application then it could be a problem, and you might have to create
multiple machine configurations. You can use the "choice.com" utility also
in FreeDOS, to select whether it is loaded or not, but once loaded it will
stay loaded until you reboot
SHARE harks back to the time when disk got larger than 32Mb, (anyone here
remember then? my first network server had a whopping 20Mb it was an awesome
size!) and when networking and multitasking workstation operating systems
came about. It was a flacky utility at the best of times, but I will try my
best to explain how and what it did.
SHARE.COM (no, it is not a sharebrokers domain name, well it is, but not for
now), provided the current status of a file or even a section of the file to
an application. Just what you would want a multiple access controller to do.
It did this by building two tables in RAM. In one table details the full
path and name of every open file was stored as the file was opened, the
other table mained details about the file locks being imposed on that file.
The details of that lock are preserved in the table until the program
specifically removes it. old DOS database programs like dBase was written to
use SHARE.COM (or SHARE.EXE they relater renamed it so it would not be
confused with the domain name ;-) and when the application no longer needed
to lock the file or part of the file the application would ask SHARE to
remove the lock.
Even on standalones SHARE.COM had a nasty problem of running out of memory,
and when it did it would issue nasty error messages. They were nasty because
they rarely ever told the truth... They would give you "Resource busy.."or
"Sharing violation..," when in fact it was just out of memory but when it
occurred it spelt problems for your application; it would sometimes lock the
file and hold it open, you generally needed to reboot the machine.
SHARE.COM has two parameters /F for the number of bytes for the files list
and /L for the number of locks. Because it stores the path you need to have
the /F parameter as long as the longest path open at any time plus a little
more for overhead (about 12) , multiplied by the maximum number of files
opened on the machine. Because each opened file could have many locks placed
on it, the /L parameter need to reflect that. If the application did not
expliictly remove locks then SHARE.COM would treat that file as single user
file.
It came as an incredibly welcome surprise that DP did not need me to use
SHARE.COM, and because network operating systems started to include all the
needed functionality for multiuser database applications, I was able to can
SHARE.COM for good.
Oh yes, to make matter worse, and this is where you might also have a
gotcha, MSDOS 4.x required SHARE.COM to be loaded if the disk was more than
32Mb, it really had nothing to do with SHARE but Microsoft in their wisdom,
thought that anyone with a disk larger than 32Mb must be using it for
networking (perhaps the primitive IBM/MS Lan Manager), and since they used
SHARE, Microsoft thought they may as well include the support for these
mammoth disks in the SHARE.COM utility... Einstein did not work at
Microsoft... I suspect late versions of FreeDOS have dispensed with this.
I use FreeDOS and DOSEMU for my DP web applications, and I am using a 500Mb
DOS partitition...
SHARE.COM would probably be useful if you were creating an IT museum, where
you need to display really old applications on really old hardware and old
operating system
Good luck
Brian
----- Original Message -----
From: "Ed Marfil, MAST UNITED" <[EMAIL PROTECTED]>
To: "'Dataperfect Users Discussion Group'" <[email protected]>
Sent: Friday, July 25, 2008 1:55 AM
Subject: RE: [Dataperf] Networking DP
The error message you're getting appears that you stored your database
.ind
file locally on your stations and is updating only the station's copy but
not the .ind file on the server. This will result in a conflict.
When running DP on a network, you can store and run the DP app program
from
the station but your database's .str, .ind, .txx and data files must all
be
on the server if you want common access to them. Only the server should
have the database files and not the stations. Very important is to make
sure all your pointers (DP paths) are mapped to the dp database server
including the index.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marcos Favero
Florence
de Barros
Sent: Thursday, July 24, 2008 7:39 AM
To: DataPerfect Users Discussion Group
Subject: [Dataperf] Networking DP
Some help is needed with networking DP.
As part of my voluntary work at health centers, I have been trying to set
up
a network -- something I have never done before. So far I have been able
to
connect 2 computers with Ethernet cards and MS-Client in a client-server
scheme.
The network seems to be ok. Then I tested the network with several of my
own
DP databases, and they all worked perfectly. But when I tried to run the
health center database, the following happened:
As long as both computers are on the same panel, everything seems to work
perfectly. However, if computers are on different panels, then sometimes
DP
gets stuck with the following error message:
DOS error no. 1
Warning
The index shows that records are present in the data file,
but the file is not found.
Do you want to:
1 - Change the Filename (for example, CLASS.DAT to B:CLASS.DAT)
2 - Delete the Index(es) if you have deleted the file.
3 - Exit to DOS and Move or Rename files.
Trying to go ahead from here produces messages in unexpected places on the
screen. Choosing 1, 2 or 3 has no effect. The only two ways I could find
to
escape from this are:
- Pressing Ctrl-Pause, which sends us directly to the DOS prompt (rather
than exiting step by step as with F7).
- Going to the other computer and exiting the panel with F7. Once we are
back to the panel list, the first computer works normally again.
Whether the problem occurs or not depends on which two panels are on the
screen. This is consistent, i.e., some pairs of panels always produce the
problem, and some pairs never do.
I have no idea what is special about the pairs of panels that cause the
problem. There are 14 panels altogether. The biggest has 15,000 records,
a file of 2 MB, and 6 links, including one recursive data link. The second
biggest has 3,000 records in 1 MB and 3 links. These are the most prone to
problems.
The problem is symmetrical between server and client.
As long as the database ran on standalone computers, it behaved perfectly.
It has been in full use for over a year now, and I do not recall a single
problem related to DP. (By the way, our users -- doctors and nurses --
are really happy about the system.)
I replicated the tests at home with exactly the same results, so hardware
faults are pretty much ruled out. And, as already mentioned, every other
DP
database I tested on the same network worked fine, even when placed in the
very same folder where the health center database was.
Additional information
Operating system FreeDOS
Memory manager (XMS+EMS) Jemmex.exe (FreeDOS)
Shell 4dos.com
Hard disk cache Smartdrv.exe (Microsoft)
Share Share.com (FreeDOS)
Network MS-Client (Microsoft)
Protocol NetBEUI
DP version 26x
Any help will be greatly appreciated!
Regards,
Marcos Florence
Sao Paulo, Brazil
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
