[DUG] Demoing at a DUG Meeting - Accredo or otherwise

[Neven MacEwan]

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
> Delphi at ns3.123.co.nz
> 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