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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
