AWS Babelfish for PostgreSQL: A chance to slip the net of some SQL Server licensing costs? Coming in 2021, Babelfish is an AWS project which provides an endpoint for PostgreSQL that is compatible with Microsoft SQL Server, the idea being to enable porting an application without having to change the code. The thinking behind Babelfish is that organisations have applications using SQL Server databases that they would …
...older websites which were written in VB and use Access databases, and are currently orphaned because the Access to SQL Server migration is non-trivial, can, or so it appears from a quick documentation scan, be migrated relatively easily by running their code under Mono. Mono uses ODBC to talk to databases including (by implication) at least some flavours of SQL Server. Given that the ODBC client API is meant to be RDBMS-agnostic, it should follow that, once your code is running under Mono it should be simple to move it to PostgreSQL by migrating the data and then swapping the SQLServer ODBC module for the PostgreSQL one.
But, I probably missed something during that quick scan, so would appreciate knowing what I missed.
I've written systems using various databases including Sybase (SQL Server's parent), Access, Oracle and PostgreSQL and used both ODBC and JDBC but have only given Mono and its VB support a fairly quick preliminary scan to see whether the approach outlined above might offer an easier migration path for a VB+access website than migration to SQL Server. I already know that Mono can talk to an Apache web-server.
I think you confuse client-agnostic with back end agnostic. Yes, ODBC is client agnostic, but the SQL you write and run using ODBC stops being back end agnostic the moment you start using any DB specific features. And no, if you try to be careful and not use DB specific features in your app, that is going to be a very, very simple app.
Replacing Access with something less likely to give you deadlocks should be pretty easy as Access' SQL is pretty limited. Though, if you've managed to run stuff on the web for years, you obviously haven't run into Access' many limitations.
You will probably have more challenges with VB. In theory, any kind of ODBC driver should let you work with VB and you can probably compile the VB in to run on .NET core – Mono is really for GUI stuff and if it's a website you probably don't need that.
Some of the stuff isn’t just translation, people stuff their SQL servers with stored procedures with query plan optimisations that are tuned for the SQL Server engine, and these are not even necessarily compatible across versions of SQL. Then there is in-memory OLTP / memory optimized tables and such stuff. Sounds like this will work for basic stuff like is auto generated by frameworks but not the deep developed stuff.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
