Is there any way to impersonate a specific database engine while running another one?

Question

This is something I would like to see while doing my day today programming works, But I've never seen such application yet. You input is highly appreciated.

Lets say we have an application that needs MSSQL server as DBMS. And suppose you just need to install it and do something. (i.e You are not going to deply it in production servers etc.)

In such a case it might be an overhead, of installing MSSQL first. I am suggesing something like a software bridge that can use another DBMS to store data. In other words the application "sees" an MSSQL instance but underneath that it might be Access. The bridge sholud do some sort of conversion.

Another example : You have MSSQL but a certain application needs Oracle. You have to purchase Oracle then. But with a something like a bridge, You can put information into your MSSQL DBMS. The bridge listens to port 1521 like Oracle so application "Thinks" there is an oracle installation.

1. Is it an idea that cannot be implemented?

2. Are there any such applications?

3. If so what are they?

Thanks... :)

Adding a Clarification : The application might be from a third party. You don't have any knowledge on internal architecture of that. you just know it uses a certain DBMS. I am trying to use a different DBMS other than the third party software needs.

Answer 1

Application usually don't depend on a specific database server, OR they depend on it for a reason.

If an application asks for oracle, or sql server, or whatever, it's because it relies on the implementation details of this specific vendor to run its SQL, its stored procedures, etc. There's no way you could emulate that with an access database, for example...

If your application just needs to run some very simple SQL (ie basic insert/select statements), it probably uses a standard driver (odbc, ado, etc.), and those drivers can accommodate every major sql database engines. In my experience, "simple applications" don't ask for a specific database vendor.

Answer 2

This is the problem that ODBC was supposed to solve :-) .

But in response to your questions:

Is it an idea that cannot be implemented?

It can be implemented.

It would be tedious and thankless work, and you would have a very limited audiance. In my opinion it's not worth doing.

Are there any such applications?

None that I know of.

If so what are they?

None that I know of.

......

Bringing in Chandrasekar's note in the comments section:

Have a look in a super user's perspective... He has a nice application but he can't use it without some DBMS. But still he is not a programmer to do something. So they need such a product

I agree it has applications, but it has a very limited audiance :) .

What you're proposing is something like the firefox plugin 'ietab', Only you won't have ie installed... so instead of embedding ie, you would need to entirely re-implement ie using firefox's rendering window.

Just my opinion : that's too much effort... It's simpler to just install a second database.

Answer 3

If this application uses ADO to connect to SQL Server and you can modify the connection string, then it's quite easy to use a different database: change the connection string! However, the other database must be able to support all features of SQL Server. Besides, the software was never tested on another database so the application might Crash & Burn.

If you can't change the connection string, or the application doesn't use ADO, things are more complicated and very close to impossible.

I've worked in the past on a project that needed to be reasonable database-independent. The database had to support stored procedures but there weren't any other restrictions. By default, we tried to support both SQL Server and Oracle. (We also supported Interbase but never advertised this.) While we did manage to keep it mostly database-independent, we did have to work around quite a few minor issues. Especially joins in our queries had some nasty problems which we just solved by adding more logic to stored procedures.

Answer 4

"This is the problem that ODBC was supposed to solve :-) ."

And it is the very same problem that SQL was intended to solve too.

It seems to me that the reason why this problem exists is that the world seemingly fails to agree sufficiently on what the data manipulation language/interface ought to look like.

I suspect that if this were solvable, it would already have been done.

Answer 5

The closest I've heard is EnterpriseDB where they have built a layer on top of Postgres so it looks more like Oracle.

But remember these databases have features covered by patents and copyright so there's a limit on how closely a competitor product can imitate the real thing.

It would probably be easier to imitate 'down' than up. For example, MS-Access wouldn't be able to imitate much of the functionality for Oracle or SQL Server, whereas there's a much better chance of SQL Server imitating a simpler DB like Access.

Answer 6

Applications usually DO depend on a specific database server. Every database implements things slightly differently - even MSSQL and Sybase, which have a common ancestor.

Any bridge, however well it attempts to abstract the differences, would leave some exposed. These would be likely to create subtle bugs in the application, which might appear initially to work, but then fail, or worse, corrupt data.

Moreover, the application vendor would not support you in such a case - they'd simply say they don't support that use case, and you should remove the bridge and install a proper instance of whatever database it was intended for.

In short, I don't think it's worth the risk of the application malfunctioning subtly, and being left without support, even if the application isn't especially important. If you dislike the underlying database the application uses, choose a different application.