Hi Andre,

You have many different options in solving your problems. I can also
see many problems in the approach you have taken.

Let me review the situation as it has been described to me.

Original Setup,

Multiple locations, btrieve database, manual/semi-automated procedure to
merge the days actions with a central database.

Proposed Setup

Single central server, all connections going to the central server, all
clients connecting via a 64 K pipe.

OK, I know I summerized it up a bit.

I also know that alot of people are suggesting multi-tier, corba, midas
(the names can go on and on)

They are all very good suggestions.
If this was a new project that was in the original planning stages, I
would definately direct you in a direction like that.

Please understand that my background is not that of a developer(software
that is).
I was raised to deal with money, large amounts of it, and to make sure
it keeps on getting larger. I know that time is money, and I am very
cautious with any suggestion that takes alot of time or money.

Therefore, the beauty of design, elegance of approach, and all the other
wonderous details, are all thrown out the window when I look at a
situation where alot of development money, engineering hours and
customer confidence are all in jepordy.
I would prefer a solution that costs as little to implement as possible.
I would also want a solution that requires no changes to the client apps
(or as little as possible)
I would also want to make sure that maintenance on the system is simple
to perform.

The idea being, to be able to institute the changes and start rolling
out the solution in days vs months.

Ok, here are the problems I see with your current idea.

1) you started off with the BDE, the BDE is not very efficient when
dealing with small data pipes. I would suggest you switch to IBObjects
- Jason has wizards that will allow a complete switch over in a few
minutes. This is quick and efficient and requires very little design
changes. (it is almost as simple as a recompile, no other solution is
this easy)
2) you are relying on a central server to always be up and working.
THIS IS A FUNDEMENTAL FLAW. XXXX happens!. If anything goes wrong at
you head office, all of the different branches are down. Even if the
head office does not go down, communication lines do fail. If the pipe
to the head office fails, then that location is down until it is
repaired. If this system is money to you, than this is totally
unacceptable. At the minimum you will want a fail over system, but the
design of that is almost impossible to implement in a few days.

SO,
based upon the following assumptions
a) you have a currently working client that as long as the connections
are low, works.
b) you have a screaming (customer||client||boss||wife) you need to
find a solution that is quick and cheap to implement.
c) you do not want to spend lots of developement dollars redesigning
the system (which you would have to do in order to switch to another
database or implementation model.

I would do the following.
a) upgrade to IBO (under Jasons pricing model, you could buy one license
and do this, but I would be fair and buy a few, he put alot of work into
it and he will be saving you alot of engineering time and money)
b) find out how many of the currently existing novel servers that are
being dumped are capable of running linux and interbase.
c) if you have a sufficient number of small servers, purchase the
remaining so that each location has a very basic linux host running
interbase - 64 MB ram and 166 Mhz Pentiums should be overkill for what
you have described so far.
c1) if this is feasible, you now have each location running the
current database schema, with the current client, it will be fast and if
the pipe goes down, you don't care. In fact, the pipe can now be up on
demand instead of a constant expense.
d) if you do not have sufficient numbers of small servers, but you do
have a few machines that can handle the load, you change your connection
routine to go through a list of possible server addresses in a
preferential order (based upon location) and if it cannot connect to one
server, it goes to a second server. This keeps the central location
system working but takes into consideration the fact that a server will
fail.

regardless of whether you go for c) or d) you will now need to have a
piece of software that will replicate the changes from one server to
another. By coincidence, the company that specializes in off the shelf
solutions for that sort of thing, is in your neck of the woods.

Without seeing your current schema, I would have a hard time giving you
optimizations, but, I would guess that it should not be too difficult to
set up.

The reason I am suggesting linux as the local host machines is because
you can telnet into the linux box, and have full control over it. Linux
is also the most supported *nix varient due to the number of companies
getting onto the linux bandwagon. NT is more difficult to have this
level of intimate control over, without some form of desktop proxy
software, wich means alot of unnessary graphic and mouse movement data
being transfered over the small control pipe.
This means the end users never need to touch the local servers because
if you need to do anything on the linux box, you can do everything you
need remotely. You can even set up shell scripts and cron events to
automate the whole process.

The end result is a system that is redundant, easy to maintain, and you
are able to implement in days vs months.

This is based upon cost as a factor. If your budget is unlimited, you
can go back to the drawing board and come up with a new design, or, try
to change your current program to operate in a fashion that was not
envisioned when it was first designed.

If you like this idea, let me know and I can flesh it out, if you don't,
let me know and I can give you a few alternitives.

If I have made some improper assumptions, correct them so that I can
give you a better solution.

best regards

Dalton



Andre Mostert wrote:

>
> >Dalton Calford wrote
>
> >would never rely upon a beta product as one of it's key components. IBO
> >is a stable product, well tested, and well, cheap. It is your
>
> Point taken I will table it with the developers tomorrow
>
> >I am going to propose a series of different solutions to your problems.
> >What I ask is that we keep all discusion of this on this list. That all
> >consultants, developers, wise-cracking hacks and anyone else involved
> >joins this mailing list and confines all comments to this list. No off
> >list mailings or discussions.
>
> To the best of my knowledge the follow the list but I will copy them on your
> email. Essentailly I have been
> charged with finding a solution
>
> Regards Andre
>