[comp.databases] dbase on two systems

law@janus.Berkeley.EDU (Katherina Law) (12/06/89)

I am recently given a project such that we are using dBase IV
to do the store inventory.  However, it is desired that there
be one PC running the inventory program and yet another PC to
do data entry at a different location, while the second PC could
update the inventory as new parts come in.  The problem is we are
not using networking, and hope that it will work with using the
comm port.  Has anybody has this kind of experience before?  What
will be a good solution? Is this possible?

While I am at it, we are also trying to incorporate a wand to the
program and the wand signal comes in from the comm port.  I was
able to write an assembly program to get the READ command to recognize
the data by writing the data directly into the keyboard buffer.  But I have
encountered a problem with this approach such that if one uses the keyboard
to enter data, but terminates with ENTER.( ie, the data is defined to
be 6 char, and the entry is only 4 char, thus one finishes with ENTER.)
Then dBase clears the keyboard buffer, and the data entered
by the wand is loss.  So can anybody enlight me on the above?
Many thanks in advance.

Katherina Law
law@janus.berkeley.edu
C
law

awd@dbase.UUCP (Alastair Dallas) (12/07/89)

I'm not clear on exactly what you're trying to do here; if you'd care to
be more specific, perhaps I could offer more specific help.  For instance,
by 'wand' do you mean 'bar code reader'?  'light pen'?

One way to do things that are too complicated for LOAD and CALL bin files
is to write a driver program such as:

main()
{

	patch INT 0x63 (or some unused number)
	exec("dbase");
	unpatch INT 0x63

}

isr63()
{

	switch (the contents of reg al)
	{
	case 0:		/* init */
	case 1:		/* read wand */
	case 2:		/* beep wand */
	...etc...
	}

}

Then, your wand can generate interrupts which leave data structures around
for your isr63() code to read.  You can then set up a LOAD/CALL bin file
that executes an INT 63.  Having separately LOADed modules to patch and
unpatch the interrupt makes it likely that you'll exit dBASE without
unpatching.

Hope it helps.

/alastair/