Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The primary benefit(s) of an Access Data Project is that <strong>(a) you get the stability, scalability, and security of a real SQL database</strong>, while <strong>(b) still using the well-known MS Access front-end and programming</strong>.</p> <p><em>(a)</em> As I'm sure you are aware, Access MDB files demonstrate a lot of problems when shared by multiple users at the same time, or when growing too large--these are limitations that SQL Server doesn't have. Beyond that, you can secure your data and prevent corruption or loss more easily on the SQL Server.</p> <p><em>(b)</em> If you've already got the front-end built in MS Access, it's fairly easy to let the program upload your data to the server. End-users get to continue using the same interface that they were before--it feels no different to them (except perhaps that it's faster!). And it doesn't require a ton of time starting the program from scratch in a .NET language (not to mention distributing/installing the new app across all your client systems).</p> <p>Are there any downsides? Well, maybe a couple: <em>(1)</em> Clients still need the Access Runtime to use the software, and must also have network access to the SQL Server. <em>(2)</em> The automated conversion is not 100%--when you run the wizard to upload the data from Access, it will do its best to convert the Access-specific SQL queries to SQL Server/T-SQL ones; if some queries fail after the conversion, you will probably need to re-write them with correct T-SQL syntax.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload