🚀 go-pugleaf

1) Yep, you have the right idea:

Typical Stock Record
==========
OnHand = Physical count on shelf
OnOrder = Total outstanding orders
Allocated = Total outstanding allocation entries
Available = OnHand-Allocated

As you allocate stock, enter a record in you stock transaction table for the
allocation. Stock transactions can have "Type"

Typical Stock Transaction Record
===========
TransactionType = [Order, Receipt, AllocationRequest, AllocationIssue,
AllocationCancel, Adjustment]
StockID
EmployeeID
Qty

2) Yep, mark parent records as 'Gone'.

3) Packing (or exporting then re-importing):
I can only comment on Interbase up to version 5. There can be good reason
for exporting and importing data to force Interbase to rebuild and balance
its inidices (to make it run faster..). But I have never actually needed to
do it. I would forget about the need for "Packing", but getting a compacted
version of the data once a week/month/6 month and year should be standard
procedure anyway.

4) No, I would recommend relationships. You will benefit from a more robust
application and good database integrity.

5) ADO will work with a Linux based version of Interbase. If you think your
application may be SQL Server or Oracle based in the future then using ADO
may help with the change. If you do use ADO then be careful about the OLEDB
provider you use ( http://www.lcpi.lipetsk.ru/prog/eng/ ). Your main
question is whether you intend to stick with Interbase, that answer will
determine what you do next for connection...ADO or Proprietry.

Mike


"Steve Kothenbeutel" <skothenbeutel@consultant.com> wrote in message
news:3d0a3063_1@dnews...
> Thanks Mike for that insight.
>
> 1) Allocating Stock: I thought about doing something like that.  I felt
that
> by putting in some sort of "marker", I could allocate a specific product
to
> a transaction until the transaction is complete or if it has been
cancelled.
> I will toy with that idea for now.
>
> 2) Deleting Stock: so, instead of deleting the employees, I shoud leave
them
> in the database but marked as "gone?"
>
> 3) Using while packing: It was suggested by somebody that a true RDBMS
> doesnt require packing as it automatically fills unused space with new
> records.  Is this correct?
>
> 4) Relations: so, I shouldnt use relationships that much in database
design?
>
> 5) ADO: is ADO solid enough?  I mean... I would like to eventually port
> something like this to linux... if that day comes... so, I am assuming ADO
> is not available to the Linux platform.  Any suggestions on something that
> would give me the power I would need for this sort of project?
>
> Thanks Mike for your assistance.  I appreciate your thoughts about it.
>
>
> Steve Kothenbeutel
> skothenbeutel@consultant.com
>
>
>
>