Good insights there, Thomas.
I never thought of it till reading your post, but of course being back-end agnostic would be an important feature of a vertical application.
Merging two disparate applications would be another good example, as you point out.
Danke!




>>>What if a not too small customer asks about Oracle, DB2, PostgreSQL or even dbf again <g>?
>Invest 15% more of your time now to work through exchangable layers.
>
>I've been doing this a long time and I"ve NEVER seen a client replace one client-server backend with another and retain the original front and middle tiers.
>I've done scads of conversions from .dbf to SQL Server, etc, but not one single switch between client-server backends.
>Are things different in the large company market?

One of my apps of last century was used in different EU country divisions of a company - as IT had grown in each country, the app had to talk to the backend of this country. (That one was not a vfp app)

Currently adding Oracle to an app working either off dbf or MS-SQL, as Oracle is the backend used by a new customer.

Here bank #2 & #3 merged in a couple of years ago. They are still not finished integrating the different IT systems - and there backend switching happened often.


>That said, since we use SPT with vanilla ANSI SQL and try to stay away from proprietary features where possible, I'm wondering how big a deal it would be to switch to go_sql, for example?
>I've seen examples of SPT code accessing go_sql tables and the code was almost identical to the code we use to access SQL Server tables.

A data access layer does not incur significant performance loss, but helps you isolate the points of difference. Almost identical is just as bad as totally different if encountered in lots of lines ;-)

regards

thomas