HELP! BIg problem with FoxPro-based POS system

#1

Hi all,

We use a FoxPro based POS system for our annual theater festival. It
draws around 100,000 people, so we can't really afford to have it not
working at any time. Unfortunately at present it is, and we're
rattling our brains to find the cause. More worrying still, even the
people that developed the application don't seem to have the foggiest.

We have four POS computers running Windows 98 (I know...), and which
are connected over an ethernet network. The Passepartout (the foxpro
app) server is DOS-based and ostensibly uses MS networking to connect
to the other machines. Everything works save for one detail: the thing
won't share its database of locations, times and acts (rather a major
snag when trying to sell theater tickets). Only one workstation is
able to use the database, which means that the rest sits around doing
nothing.

If I try to open the system from the first workstation, I am greeted
by a chippy: "Error 107 operator_operand type mismatch". A 'file
repair' option take care of that, but each subsequent user (from one
of the other three terminals) is told that "lok_res.dbf is in use".
The fact that I am not able to use the database without repairing it
is NOT reassuring, but at the moment I'd do anything (well, almost) to
get the thing running. There's a free ticket (well, two) for anyone
coming up with a solution. If you're not able to come to the
Netherlands, just be assured of my eternal gratefulness.

Replies to this group of my home e-mail (ilja (AT) noorderzon (DOT) nl), and many
thanks in advance.

Ilja Nieuwland
www.noorderzon.nl

#2

Thanks for the answer! But I really don't know whether the problem
lies with the app itself, since it opens all other databases without
problem - or is that a very blond way to think?

Anyway, if you want I can send you the dbf + index file to have a go
at... It looks a bit odd when I open it in a DBF viewer, too, the last
record being occupied with something that was supposed to be deleted.

Cheers,

Ilja

"Emporium" <MYthe_emporiumSPM (AT) hotmail (DOT) comDELETE> wrote

Quote:

I think by default Foxpro DOS insists on using "SET EXCLUSIVE ON" if not specified therwise, which in a networked evironment it will
cause havoc. When coding I use the set exclusive feature, only in maintnance tasks which I assure single user operation first.
First line of most of my modules is "SET EXCLUSIVE OFF". Win98 also seems to be persistant on file locks, so even though someone
releases the file, the server does not see it (I believe there is a registry value you can tweak to disable persistent locking).

On an app we had done for a client, we find that for multiuser it was easier to use SCO Openserver Unix with Foxpro for Unix
installed, used all the same dos code, and users would just use a terminal emulator (TinyTerm) on thier PC and use the session
directly on the server. This was the best way we found since everyone is on the same machine, and the PC could be anything from a
dumb terminal, an old 286 or 386, or even a super fast new machine. If we needed more horsepower, we just updated the main machine,
and it was transparent to the users. We used this method successfully to link a main office of about 60 users, with another 150
users remotely in about 5 other offices via a fractional T1.
In 10 years we have yet to have a file mangled beyond hope, and downtime has been at most 1 day in 10 years (too account for the
once a year reboot, and occasional OS updates. Server was running Dual CPU, redundant power supplies, and a 10 disk Raid file
system with data striped over 4 disks, then mirrored on another 4 disks, and 1 other DISK dedicated for parity of each chain.
Needless to say that this hardware also had a major role in decreasing dowtime, and downtime is expensive when you have nearly 100
or so employees doing nothing while they wait for the system to come back up.
I know Dennis Allen did alot of work on Foxpro for Unix getting it to run under Linux. I have not tried it myself, but it seems
like a pretty nice alternative, and on one of the apps he has on his page, he includes the Foxpro for Unix Runtime, so you can take
your .FXP compile under DOS, and run them on a Unix machine.

Kind of difficult to isolate the problem, unless someone looks at the code to see how the files are being opened and used. If this
app wasn't designed with multiuser in mind from the beginning, then trying to hack it to work in a multiuser evironment is not
always trivial. Best to assume multiuser at first and take the time to code it right, than the opposite (mutliuser app will work
even with one user, but not necessarily true in reverse direction)..

Good Luck.

-Tony

"Ilja Nieuwland" <ilja (AT) mac (DOT) com> wrote

Hi all,

We use a FoxPro based POS system for our annual theater festival. It
draws around 100,000 people, so we can't really afford to have it not
working at any time. Unfortunately at present it is, and we're
rattling our brains to find the cause. More worrying still, even the
people that developed the application don't seem to have the foggiest.

We have four POS computers running Windows 98 (I know...), and which
are connected over an ethernet network. The Passepartout (the foxpro
app) server is DOS-based and ostensibly uses MS networking to connect
to the other machines. Everything works save for one detail: the thing
won't share its database of locations, times and acts (rather a major
snag when trying to sell theater tickets). Only one workstation is
able to use the database, which means that the rest sits around doing
nothing.

If I try to open the system from the first workstation, I am greeted
by a chippy: "Error 107 operator_operand type mismatch". A 'file
repair' option take care of that, but each subsequent user (from one
of the other three terminals) is told that "lok_res.dbf is in use".
The fact that I am not able to use the database without repairing it
is NOT reassuring, but at the moment I'd do anything (well, almost) to
get the thing running. There's a free ticket (well, two) for anyone
coming up with a solution. If you're not able to come to the
Netherlands, just be assured of my eternal gratefulness.

Replies to this group of my home e-mail (ilja (AT) noorderzon (DOT) nl), and many
thanks in advance.

Ilja Nieuwland
www.noorderzon.nl

#3

Two things you pointed out:

one is that you had an error Operand Type Mismatch which a disk repair
fixed. That might have altered (an albeit damaged) key database to
the operation. If it was early in the program it might have been
something the people made to configure the system, Since I know you
have good backups, I'd take a couple units off the net set one up as a
server and workstation and test them with the backup if it works then
locate and copy ofer the primary data databases and indexes from the
damaged server's HD to the test server until you can get everything
needed to come back up. Then try that as the main system.

Second is if if you moved the database server or workstation to a new
computer since the last festival you might have forgot to configure it
properly to share the files among the other computers (doesn't have
the proper networked folder/drive designations, etc.)

I noticed a lack of mentioning 'database is locked' or 'record is
locked' errors which makes me believe it either does notreally have a
sharing issue, or it isn't even trying to use the servers' database.

ilja (AT) mac (DOT) com (Ilja Nieuwland) wrote in message news:<76112bbc.0308040750.1db93cda (AT) posting (DOT) google.com>...

Quote:

Hi all,

We use a FoxPro based POS system for our annual theater festival. It
draws around 100,000 people, so we can't really afford to have it not
working at any time. Unfortunately at present it is, and we're
rattling our brains to find the cause. More worrying still, even the
people that developed the application don't seem to have the foggiest.

We have four POS computers running Windows 98 (I know...), and which
are connected over an ethernet network. The Passepartout (the foxpro
app) server is DOS-based and ostensibly uses MS networking to connect
to the other machines. Everything works save for one detail: the thing
won't share its database of locations, times and acts (rather a major
snag when trying to sell theater tickets). Only one workstation is
able to use the database, which means that the rest sits around doing
nothing.

If I try to open the system from the first workstation, I am greeted
by a chippy: "Error 107 operator_operand type mismatch". A 'file
repair' option take care of that, but each subsequent user (from one
of the other three terminals) is told that "lok_res.dbf is in use".
The fact that I am not able to use the database without repairing it
is NOT reassuring, but at the moment I'd do anything (well, almost) to
get the thing running. There's a free ticket (well, two) for anyone
coming up with a solution. If you're not able to come to the
Netherlands, just be assured of my eternal gratefulness.

Replies to this group of my home e-mail (ilja (AT) noorderzon (DOT) nl), and many
thanks in advance.

Ilja Nieuwland
www.noorderzon.nl

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

HELP! BIg problem with FoxPro-based POS system

comp.databases.xbase.fox comp.databases.xbase.fox

HELP! BIg problem with FoxPro-based POS system - 08-04-2003 , 10:50 AM

Re: HELP! BIg problem with FoxPro-based POS system - 08-05-2003 , 02:22 AM

Re: HELP! BIg problem with FoxPro-based POS system - 08-14-2003 , 03:21 PM