Max
>> One of our competitor products was designed Interbase only
Read - Exonet (I'm allowed to say it even if you aren't)
And this is exactly my point they probably chose interbase because
it was a borland product (its also developed in Delphi), Actually the
whole history of Exonet is that it was an inhouse product hence the DB
choice was not critical though it did come back to bite them..and Rohit
would find the same thing if he tried to become a multinational.
Point is if you were to implement an SQL based multitier system as of
now there is little forseeable advantage in not using MSSQL/MSDE and
don't give the IB/Firebird small footprint BS, My monitor driver is
bigger than IB now - its irrelevant
> What exactly do you disagee with in our product? I'm interested to
see what
> bit of our design and implementation would cause disagreement and
with what?
The main issue for me is the fact that as a systems implementor "Profax"
(and don't jump down my throat here as I'm sure it has developed since I
looked at it) was to tightly bound, Internally it may be 3 tier but it
wasn't exposed as such, I seldom implement a system with expanding the
DB or integrating another system, I remember Paul describing it as
'compressed n tier'. The profax philosophy was profax centric whereas
any product I would work with is simply a component of a larger system,
Yes you have maxbasic, odbc (we talked about ADO I recall) and probably
you can extend the DB but that is not the point, your paradigm has
always been that the technical stuff is profax's domain and that works
when your implementors are endusers and accountants, it doesn't make for
a product that can be used as a component by other technicians
As far as I'm concerned MYOB has that area covered, My advice would be
in order to grow your product (and I forsee it being a v difficult
market in the next few years esp if M$ start playing tricks) would be
expose your layers 6 ways from sunday, use MSSQL in a
INSERT/UPDATE/DELETE mode, middle tier all the data integrity (RI in the
DB but that can be done in a case tool) COM business objects and trade
on your excellent UI skills, Then you would be a seroius contender for
MySAP, Narvision etc
And if you want a technical challange solve the 3 tier App/ 2 tier
reporting conflict, It has always annoyed me that to report out of
systems you have to reconstruct the BO's in the report generator with
the incumbent chance of error. I see something that returns XML from a
selection of related BO's, Printed out using XML-FO templates?
Stay away from stored procs! The main reason I use them is to solve
reporting issues, I have to disagree with Rohit here (I don't know if
his app is 3 tier but it sounds like hes in 2 tier hell), Any progress
down the DB server as app server route weds you to the DB server, I've
designed a couple of systems based on the paradigm "the db is good if
you can let someone edit it with access and they can't damage it" and
eventually had to back off as the overhead on the database server became
too much (esp as I'm fond of normalisation)
Thats about 10c worth
Neven (Soon to retire to sunny Hawkes Bay and grow truffles)
Max Nilson wrote:
Neven MacEwan commented:
The Profax/Accredo story reminds me of Bristol making cars,
it was said that they wouldn't buy in a component for 5
pounds if they could make it for 20, I've seen 2 Bristols on
the road in my life.
And I've never seem one, unless I did at the Southward Car Museum and didn't
notice.
I admire there UI philosophy (If we don't like it we rewrite
it ) but can't agree with much else in the product.
What exactly do you disagee with in our product? I'm interested to see what
bit of our design and implementation would cause disagreement and with what?
Which
leads me to think (somewhat vaguely related)
1/ If Delphi is OO and encapsulated then why do some of us
insist on ignoring that at a macro level (and reinventing things)
We do use a lot of third party components for areas that we are not good at,
or that it is not cost effective to develop component in. Currently we use
Indy, Rave, TeeChart, Abbrevia, Virtual Treeview, madShi, WPTools, Toolbar
2000 in the application.
What we do not use is most standard Windows UI component, or any other
people components. Originally we used Infopower, but as soon as we needed to
extend the control to perform correct behaviour required by use and our
users they started costing too much time to modify. So it eventually became
cheaper to create own own control library and use that. Now that it exists
and is stanle we can extend and modify its behaviour extremely rapidly.
4/ Finally I'm dying to see how Paul et al does the DB
independance with triggers and stored procs trick,
intellectually because it is enormously difficult and fraught
with danger, and philosophically because its relatively
pointless.
I must disaggree here. One of our competitor products was designed Interbase
only. Then they hit the real world and needed to support MSSQL. And then
they got bigger and had to support Oracle. There codebase is now a large
mess, and they spend to much time trying to keep three sets of triggers etc
in sync. Why not realise that to cater for a wide market you must support
what the customers demand you support and design that in to start?
Cheers, Max.
_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi
--
Neven MacEwan (B.E. E&E)
Ph. 09 620 1356 Mob. 027 4749 062
New Address Details
===================
MWK Computer Systems
1 Taumata Rd
Sandringham
Auckland
Ph 620 1356
Fx 620 1336
_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi
