Re: Throughput and storage requirements questions for modern vs old database processing apps

"John Becich" <jbecich_at_nospam.net> wrote:

> "Paul Linehan" <plinehan_at_not.a.chance.ie> wrote

> > Make sure that they'll give you the source code of the application
> > (sign an nda if necessary) and make sure that you can obtain a copy of
> > the development environment - I looked on the proiv site and can't
> > seem to find the pricing.

> Is that some sort of a doomsday defense strategy, in case the vendor
> disappears? You've got a good point, BTW.

Sort of. If, for example, your client had the source code, and sloppy legacy coding is the problem, it *_might_* have been possible to get around some or all of the problems - adding indices - removing/archiving data.

But, you still have to find out if it's the network, the server, the clients or the app - so this is theory - if indeed it is the app.

Also, with the source, the customer can even add functionality from time to time - or pay someone to do it - say a remote worker from a cheap country?

> I'm not sure my client wants to
> engender the responsibility of holding that source code.

All he would be doing is protecting his investment in the system - Essentially, as it stands, the thing is a black box - with the source, at least there's a *_possibility_* that some meaningful work could be done in the event of a repeat of this scenario 5 years down the line?

> My strategy so far
> has been to insist, from any candidate, that the new software have the
> ability to export its data to some format that allows a subsequent
> migration.

That indeed is an absolute minimum - although without the app source code, it may be difficult to figure out what some of the fields are.

> Our existing system lacks that, so pulling the data out will be
> a considerable job.

Not necessarily - if they're Clipper tables, any programmer who works in this area should be able to extract the raw data - that's bread and butter sort of work.

> I've done that before, writing C code to mechanize the
> process of pulling data from weird places.

Haven't we all? 8-)

> > if you had the source of your
> > Clipper app, it would be relatively easy to port it to another
> > environment (like Delphi...).
 

> Tell me more. I can communicate with the author. He's still around. But
> what would Delphi do for us? At least it might be a means of exporting the
> data from the old system to flat, delimited text files.

Delphi could certainly do that, but then I imagine that there are a host of developers in a host of different environments who could get the raw data for you.

If you are not in the business of writing applications, then an off-the-shelf solution may be for you - However, if you have the source and a development environment, you will

1. never be caught like this again

and

b) will be able to enhance (or pay for enhancements - which is what you are going to have to do with your customisable system anyway!!) the system.

The reason that I go on about Delphi is because it's what I programme in and I am pretty certain that there's a system out there with source that could be purchased *_WITH SOURCE_* relatively easily. Supplying the source is somewhat of a tradition in the Delphi world - and believe me it's not the first time that this scenario has cropped up.  

Anyway, best of luck - and don't forget to let us know where the bottleneck was.

Paul...

--
Paul Linehan

plinehan at yahoo dot com/linehanp at tcd dot ie

I drink to keep body and
soul apart - O. Wilde.

"Mens sana in campari soda" - anon.