Re the comment above “Whether the back end database is MS-SQLerver or Progress is frankly immaterial”. I am not sure that this is entirely true given that the context for this debate is that IRIS are proposing to deploy an application designed and written for the Progress database on MS SQL Server. Whilst databases may conform to a generic SQL standard for access this doesn’t mean that they implement tasks in the same way – locking strategy is a good example of this. Furthermore, code written in Progress 4GL and targeted at a Progress database will not necessarily be suited to deployment on MS SQL Server - record v set handling can be such an issue. Many database design decisions will have been made some years ago on the basis that Progress was the target DB along with key implementation decisions e.g. about where to locate business logic (business rules layer or stored procedures). These decisions can have a big impact on scalability and performance. Add to this any potential limitations in the Progress Dataserver technology for handling MS SQL Server capabilities and the net result may be a slower and less scalable end-user applications plus added developer complexity. The idea of database independent platforms and 4GLs has been around for a long time but developers invariably end up targeting their solution at a specific database platform to optimize scalability and performance and minimise code and release management complexity. It is true that some reporting issues can be addressed by warehousing but this then introduces a separate sub-set of reporting capabilities in addition to those built in to the core package – which of course adds complexity for all involved. Furthermore, the supplier needs to provide database management tools and support skills for multiple databases which means added resource commitment. Sooner or later the supplier will realise that support for one database platform e.g. Progress or MS SQL Server makes much more sense than two e.g. Progress and MS SQL Server.