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

> > *_WHATEVER_* you do, when you get the new app, make *_SURE_* that you
> > have the source code and that it is developed in a reasonably
> > mainstream development environment - get your client to invest in one
> > copy of the environment so that they can hire someone to "tweak" it if
> > and when necessary.

> Hmmm. I am impressed by how strongly you feel about this. This would only
> be of interest if the parent company disappeared...which could happen, of
> course. I guess that's why big companies like other big companies, like
> Microsoft and Oracle; for their sustaining power.

Having the source and being able to modify it also <OpenSourceJargon>

    *_Empowers_*
</OpenSourceJargon>
you, the end user. Recently listened to a talk by Alan Cox - the chief Linux kernel maintainer after Linus Torvalds himself.

Now, it's fair enough that the people who sell you the system charge for it and if they give you the source, also that they prevent (via contract -- NDA &c.) you from selling it on to others, but if you have the source and the development environment, then you will have the freedom to add features &c.

You will not be hooked into a spurious upgrade path if you don't need it ("Oh, we don't support that in version 3 anymore, but if Sir would care to purchase 5, then we'd be glad to help") - if you have Microsoft, then you're also hooked - try and use an old version of Excel and see how much support you'll get - and Oracle are the same for their databases.

Borland also will try and get you to use the latest version of Delphi, however the difference between them and the other vendor is that they appear to go to great lengths to ensure backward compatibility - i.e. if something compiles on version 4 today, it will compile on version 9 in 5 years time - try that with VB!!!!

> > >> Also, I'm pretty sure that there are programmes out there that can
> > >> give you reports on network usage, so you could look into that also -
> > >> if the network isn't under strain, then adding more capacity is a
> > >> waste of time.

> I would doubt that, unless I rent some kind of network analyzer. The
> network has to be changed anyway. 10BaseT is obsolete.

Fair enough, - if it's going to be done anyway - just don't do the network and the machine upgrades at the same time so that at least something is learnt from the excersise.

> > Fair enough, but can you lay your hands on a network analysis
> > programme? Can you ask for access to the server durning the busy time
> > (don't use PC anywhere!!) and bring up the task manager and just look
> > at the numbers - or just ring them up and ask someone there who has
> > (IQ > house-plant) to do this - it *_may_* be that your network is
> > fine.

> No. This isn't in the cards.

It's a pity - this is trivial!  

> > Ask about things like "mission creep" and what about archiving stuff -
> > i.e. can the app cope with data being added indefinitely - what about
> > removing/archiving redundant/old data?

> Now you have brought up a very good point. The new app should be able to
> "archive" old data, to get it out of circulation.

See what your vendor says about that - also what about adding data, removing it and then *_re-adding_* it - say it was archived by mistake - we had a problem of that nature once - had to create a new SKU - completely messed up parts of the reporting.

With source, this isn't a problem.

> > It is *_CRITICAL_* that you do this before changing anything. If they
> > wanted a doctor, they wouldn't be too happy if he consulted over the
> > phone - they can't expect you to do the same.

> I appreciate your proficiency, here, but I prefer to shotgun sometimes in
> the name of keeping costs down.

Yeah, but you risk firing with a blindfold on.

> The network is obsolete anyway. Not much
> sense in performing an autoposy on an uninteresting cadaver.

OK, fine, but see remarks below.

> Sometimes too
> much science makes bad business sense. Besides, it will suffice as an
> experiment if the customer will simply use the new W2K Pro workstation with
> its big pipe to the server, and report their impressions to me.

I suspect (all caveats apply) that this won't succeed - if the W2K box was like greased lightening, they probably would have told you already.

> This is one
> case where nagging makes more sense than a mountain of science. They will
> do it. I'm nagging them, and they are motivated finally.

Warn him clearly though.  

> > What are the stats on this? Do you actually have any? On what basis do
> > you say that there was a jump?

> The "stats" are the impressions of the customer.

Hmm....

> > Well, on the Borland newsgroups I have seen people writing about this
> > issue - many people have issues similar to yours and I know that
> > people have mentioned the limits of file server databases, one of
> > which was the size of the tables - this does not happen with rdbms
> > server systems - it's not that RDBMS systems aren't affected by size,
> > it's just that they're designed to grow better.

> Ooo. Good point. I should ask the author of our existing system if it is
> relational or not. Do you know? It was written in Clipper with Comix
> databases.

It is *_not_* relational - Clipper tables were not designed to work in this way.

Things like referential integrity - i.e. Foreign keys are not enforced by Clipper apps - you have to code it AFAIK.

Basically an RDBMS is a server (IF THE SYSTEM HAS BEEN PROPERLY PROGRAMMED) - if there is more data processing, then a *_good_* system will have so this increase in work occurs on the server machine - the client will have no extra work to do - it's a THIN CLIENT.

With tables, all the thing is doing is fetching data back and forth - the processing is done on the client - it's a FAT CLIENT. With tables you can never be a thin client.

> > This is why I'm so interested in seeing the stats from the task
> > manager - it *_may_* be the app, but it could be simply a network
> > bottleneck, or maybe just doubling the RAM on the server or
> > workstations might solve the problem for a few years.

> Yes, yes, yes. If the customer uses the W2K station, several variable will
> be "improved" at once, and I can re-evaluate dramatically.
> I have already enhanced hard drive access and I've doubled the RAM, and
> quadrupled the processor, in the server, to little avail.

Then I respectfully suggest that it's not the server.

> > However, you can spend all the money you like on fancy new clients and
> > if it's the app, then all you'll get for your trouble is Free Cell for
> > the floor people to play while they're waiting for the system to
> > respond.

> Like I said, I will bug them to use theW2K client. It's been in place for
> months. They'll do it within two weeks. And they can't do ANYTHING new at
> this point without replacing the clients. The only possible way to keep
> them would be to repair the database app, and I don't think that's a serious
> option. There comes a point when repairing old stuff doesn't make sense.

I thiink that the other poster Jim Kennedy warned that changing the clients to W2K mightn't make any difference - if it's a DOS programme, maybe it's limited anyway - i.e. even if you give it 200MB of RAM it'll only use 640KB or whatever - I warn you that I am not an expert in this area. I think that he also mentioned API changes...

Just be careful that if you go to the trouble of forking out lots of loolah for new workstations, that your client doesn't get pissed off that nothing has changed and that his expensive machines are no more than Free Cell servers.

Anyway, I'd be interested in what transpires - let me know via email if you post here after a gap - use the yahoo address.

Rgs.

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.