You are reading a single comment by @chez_jay and its replies.
Click here to read the full conversation.
-
Having done a bit of reading, the default is to store everything as a single file, but I have overridden that.
I have decided to deliver it in Access as the only available tool in the given timescale, but caveat it as a working model/proof of concept which isn't necessarily scalable to a proper DB. I'm fairly confident of the basic data model, though.
Some of the business problems described by the data actually relate to insufficiently controlled end-user developed applications (EUDAs if you must), which is ironic, but I think could actually be used as political leverage for someone else to find a way of getting it into SQL Server/similar as you suggest.
chez_jay
Praise be.
An Access DB is made up of two parts: The front-end (forms etc) and the data store which is a file that's accessed via ODBC, with the Microsoft Jet driver.
Once you've got it working in access, you can swap out the Jet DB for a SQL Server connection. I've never needed to do this, but I've heard it can be less painful than migrating from Py+SQLite to Py+MySQL, since Jet behaves more like a conventional db.
Then while it's running in MS SQL server with your Access front-end, build the strategic front end in something else.