Tony,
Its a case of justifying the use of technology. For a 5 workstation setup,
IMHO, MIDAS is an overkill. Its also a case of thin client vs traditional 3
tier client / server. With thin client, there is no installation on the
client end - thus saving money (and sleep!).
As for IB, the answer is no - did not have to.
Regards,
Dennis.
> Ah Denis - Predictable responses from A Web Man V a Midas
> Man. Midas is
> pretty cool - dont knock it until you try it! But then have
> you tried IB
> lately?
> 2. Database backend should not be an issue for you. You
> ought to make your
> code independent of the database backend, for example, in
> case the database
> vendor decides to drop the product. It is not difficult to do, if you
> structure your code well.
>
> This is pretty difficult to do because of feature differences
> unless you
> adopt a lowest common denominator approach OR a three tiered approach.
No not really. All my code I wrote in the last 6 months ought to port to
another database in a matter of minutes. Its a matter of structuring your
code properly - using a 3 - tiered approach *inside* your objects. On the
top, I have objects that implement the business rules, then a persistence
layer that is called to read / write data. This is done so that the
business rules objects need not know about database / SQL / etc. In fact,
the persistence layer can write it out to an INI file, web server, etc. Its
a matter of swapping in a persistence layer object to cater for different
storage requirements. The database persistence object then constructs
queries to fire against the database backends. The objects it uses to
create these queries are coded to match a particular backend, eg., you'd
have an object to create an update query for SQL server, one for IB, one for
Informix, etc. A factory object is then used to instantiate these objects,
so to swap databases, its a simple matter of writing the backend specific
query generators, and registering them with the factory. Easy really.
> Exactly, and this is why I sugested changing the focus from
> Features to
> System Design concepts.
> I think our point is not that SQL7 does not work, but simply
> that it is much
> much easier and rewarding doing it with IB. Dont forget that
> we were not
> always IB Fans... We came from somwhere before.
However, "easier and rewarding" are highly subjective matters. IB may be
rewarding for some but a real pain for others - the same can be said for
other database engines, eg. SQL server. Database is only a tool amongst
many, in the process of providing a solution to your clients.
> My point is, I am not saying that IB is no good or does not
> work, but I
> cannot understand what all the fuss about SQL server is about
> as it has
> worked very well for us and that is all that matters.
>
> Couldn't agree more, but after all this is a Borland
> sponsored list, so if a
> thread turns into a full on comparison of IB V XXX, what do
> you expect me to
> say? Most of the time I stay quiet.
And that is the point of my post, in that it is fruitless to compare XYZ
database against IB, because there are other more important issues to
consider - and as I have said before, database is only a tool - why limit
yourself to one? <smiles> <sits back> <relax and enjoying the view from my
window> ... <ah the motorway is not very busy> :).
BTW, changing the topic, how do people feel the NZ cricketers will fare
against the aussies, now that we have white washed the windies?
Regards,
Dennis.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
