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

[Leigh Wanstead]

Hi Paul,

You are very kind.

Why not spread these really interesting topic into multiple sessions, so we
can absorb it nicely?

I am interested to know topic 1,2,4,5,6,7,8.

Regards
Leigh
http://www.salenz.com

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz
[mailto:delphi-bounces at ns3.123.co.nz]On Behalf Of Paul Heinz
Sent: Thursday, 18 August 2005 2:08 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Demoing at a DUG Meeting - Accredo or otherwise


Hi, all.

First off, since people have asked, what is Accredo?

In terms of WHAT it does, Accredo is a mass-market business application
suite for small to mid-sized businesses i.e Receivables, Payables,
Inventory, Manufacturing, etc. As a category, it's also called ERP software
in some circles. This was originally short for 'Enterprise Resource
Planning' but nowadays, it seems to be used more to distinguish simpler
accounting applications (MYOB, Quickbooks, etc.) from their more
sophisticated cousins.

Now, I don't think any of this is that interesting to DUG members so if
anyone cares enough to want to know more, see www.accredo.co.nz

To my mind, it's HOW Accredo does things that is likely to be more
interesting to DUG memebers. So what are some of the things that might be
interesting or different?

1. UI CONTROLS

We wrote and use all of our own UI controls ie. Edits, Lookups, Grids, etc.
Why? Gadget-based control composition, flicker-free optimised painting (very
Terminal Server-friendly), and rich keyboard handling that 'Just Works'
without developer intervention (no FormKeyPress futzing!)

2. FIELDS AND DATASETS

We wrote and use all our own TDatasets and TField equivalents and actually
use the Data-aware model extensively. Admittedly, we had to rework and
extend it since it's validation model is too weak -  OnChange and OnValidate
don't really cut it.

3. DATABASE ENGINE

We wrote and use our own database engine - a network file based ISAM style
engine with in-memory transaction processing (similar to DBISAM). In fact,
we were using DBISAM's SQL implementation over the top of it, but it's
proved to be quite non-standard in terms of SQL, and has a pretty limited
query optimiser so we've recently written our own SQL query processing
engine to replace DBISAM which is significantly faster.

4. DATAMODULES AND BUSINESS OBJECTS

We use forms and datamodules extensively and surface our datamodules as COM
automation enabled 'business objects' which are usable both from MaxBasic
and other COM clients. These are use a lot when integrating Accredo with
other products (Point of Sales, Sales Form Automation, Web Front Ends, etc.)

5. MAXBASIC AND AUTOMATION

We wrote and use our own scripting language (called MaxBasic) which is
essentially a VBA subset and can talk to all the usual COM automation
servers (Word, Excel, ADO, etc). The application is fully scriptable with
macro recording as well as various Script Event hooks for our forms (OnSave,
OnInsert, etc.) to enable users and resellers to extend and customise the
product.

6. REPORTS AND DESIGNERS

As developers, we don't write run-of-the-mill reports - most of our reports
are generated from Layouts which are a TDataset based reporting
infrastructure which is customisable by the user. We also wrote and use our
own MaxBasic-based banded report designers for producing fancy or custom
business reports and documents i.e. invoices, statements, product labels,
etc. We are in the process of writing our own MaxBasic-based Form designer
for allowing others to further extend and customise the product.

7. MASS MARKET VS VERTICAL MARKET

Accredo is a mass-market application that works out-of-the-box to satisfy
the common 80% of a businesses requirements. It's also extensively
customisable so you can satisfy the 20% of the businesses unique (or
vertical market) requirements. Yet we don't want to limit the ability of our
customers to easily upgrade to later versions of the common core so how can
you design the application to reconcile those two apparently conflicting
goals?

8. SUPPORTING MULTIPLE SQL ENGINES

We are also looking to add a SQL-based version of Accredo in the mid-term
future, supporting initially Firebird/Interbase, SQL Server, and Oracle. In
the future, maybe Postgresql, MySql, or DB2 might warrant support. What is
probably interesting about this is the way we plan to support different SQL
engines from one codebase.

You can't write SQL and stored procedures and have them portable across all
SQL engines. All the vendors have their own wildly divergent syntax and
semantics e.g. PSQL, IBSQL, MS Transact-SQL, Oracle PL/SQL, etc.

So the 'accepted wisdom' with respect to business rules and SQL seems to be
to either give up on stored procedures, triggers, etc. and use a middle tier
for all business rules (i.e. an application server) or to pick a single or
limited set of SQL engines (just SQL Server for example) and write stored
procedure code for each of them and only them.

But wouldn't it be better to be able to write portable SQL and portable
stored procedures? If only there was a standard for stored procedures and
the various engines all supported it. But they don't and won't so you have
to give up on this, right? :-)

Anyway, so there are 8 things which might be 'interesting' about Accredo to
DUG members.
Questions and Opinions welcome.

Regards,
  Paul Heinz

















_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi