Subject RE: [IB-Architect] Re: A few more suggestions
Author David Schnepper
Louis --

Thanks for the details of your application -- I see why you added
customization features.

Now, another question -- what is the problem with having the schema
modifications made by a client-side tool
(like you do currently) -- eg: why does this need to be in SP ?

Dave

-----Original Message-----
From: Louis van Alphen [mailto:lja@...]
Sent: Wednesday, June 07, 2000 3:25 AM
To: IB-Architect@egroups.com
Subject: [IB-Architect] Re: A few more suggestions


This customisation stage can happen any time during the use of the
application (engine). Our system in particular is a tracking and stock
control system for skin tanneries. The system runs the entire production
floor from receiving to sales. The client organisation's turnover is 1200
hides per day which translates to ZAR1M per day (ZAR6.50 = US$1) !!

The user defines the attributes for the items they are tracking e.g. size,
weight, grade, etc.
But their requirements change e.g. they want to add a colour and finish
property. Our engine allows them to do this with the configuration module.

Then their requirements change even more wildly. They want to track the
actual livestock coming in for slaughter and track the carcasses through
the abattoir right down to the box. This provides them with traceability
from livestock to box of meat and hide. As can you imagine, the attributes
for livestock is quite different from hides e.g. live weight history,
owner, type, etc... We have succeeded in providing the client organisation
with a tool to define these items, their attributes and the relationships
with other items at any point in time (Read create tables, FKs and lots of
SPs under the hood). The client application builds the forms at run-time
based on the schema, so the next time a particular item form appears, any
changes in attributes are visible.

>From our point of view it may not be the best approach as they can now do
everything themselves as opposed to using us to add functionality and
getting paid for it. However, our existing customers are often in rural
areas and also cannot justify employing IT staff. From there also the
decision to use IB as opposed to using other DBs that require more admin.

I believe that we have ended up with a product that can be fully customised
by the user to fit into his/her business process instead of having to
update the business process to fit in with the system. This is where we are
(hopefully) one up on other systems.

Louis van Alphen


(They do not have ANY IT staff). I suppose from our point of view

>Message: 4
> Date: Tue, 6 Jun 2000 09:41:59 -0700
> From: David Schnepper <dave@...>
>Subject: RE: A few more suggestions
>
>Louis --
>
>Thanks for the description of your application.
>Is this "customization" stage a one-time setup issue at install, a
>"rare-event" done by time-to-time by the customer
>(eg: every few days), or an on-going change (meaning it could change
several
>times a day) ?
>
>What is the particular problem with having a client-side tool perform the
>"Create_Table()" functions?



_____

<http://click.egroups.com/1/3373/4/_/830676/_/960374049/>
<http://adimg.egroups.com/img/3373/4/_/830676/_/960374049/>

_____

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com






[Non-text portions of this message have been removed]