The correct divide and conquer

debugg

I have written something using Access.

Time passed, and it seems that Access won't do. I need something a little more serious - not just from the DB point of view, but from the UI point of view too.

So I did some thinking, and had an idea. As for now, I will leave the DB in Access. The UI - I need to change to PHP, Perl, VB or Delphi.

As you can see, everything is kind of still in the air and can change from time to time - the DB can be MSSQL, Access or anything else, and the UI can be PHP, VB, and so on.

I really do not intend to write everything from scratch for each combination (VB-Access, PHP-MSSQL, PHP-Access, etc) and these combinations are nessecary (so please don't try to talk me out of it - it's not the point).

Therefore, I want to divide the application into 3 major parts: the DB, the UI and the "engine" that connects the UI to the DB.
* DB - we all know what this part does
* UI - this part gets "requests" from the user and returns results to the user
* the "engine" - this part gets "requests" from the UI, talks to the DB and returns results to the UI

Please note that the engine is not ODBC/ADO/DAO/etc - it contains it, but its role is to connect the UI to the DB without knowing how and what language the UI is written in.

The advantage is that I can replace the DB and the UI parts as much as I want, but the "engine" will stay the same.

I know how to create the DB.
I know how to create the UI.
What I don't know is how to create the "engine" - how? what language is more suitable for this task? in what way? is it possible at all?

For example - if I write the "engine" as a DLL in VB (which is the prefered language because the application is in Access - VBA), will it be possible to use this DLL via PHP, Perl?