StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Your question is too vague to give more than just general advice. If you have already developed other .Net applications, then the approach to developing this new application should not really be any different.</p> <p>Database considerations:</p> <p>The only things to bear in mind when using MS Access as a back-end database are:</p> <ol> <li>Scalability - MS Access does not scale very well and is only suitable for a small number of users *EDIT: Numbers vary depending on the type of activity the users are performing - for a reporting solution, Microsoft themselves suggest that up to ~100 concurrent users is the maximum - this <a href="http://download.microsoft.com/download/5/d/0/5d026b60-e4be-42fc-a250-2d75c49172bc/when_to_Migrate_from_Access.doc" rel="nofollow noreferrer" title="white paper">white paper</a> provides more information * </li> <li>Security - MS Access does not offer the same sophisticated levels of security that you will find in other database products (SQL Server, Oracle, MySQL)</li> <li>SQL Syntax - there are some subtle differences in the way you write certain types of query for MS Access</li> <li>Other Limitations - MS Access does not support stored procedures, so all your data access code will have to use inline SQL Commands (command.Type = CommandType.Text) <ol start="5"> <li>The maximum database size supported by Microsoft Access is 2GB - keep an eye on the growth of the database</li> </ol></li> </ol> <p>Design considerations:</p> <ol> <li><p>Does the existing MS Access database already have some user forms and code modules in it? If so, you could use these as the basis for your application - MS Access uses Visual Basic for Applications (VBA) as it's programming language and there are no tools/utilities that I know of that will port VBA to VB.Net</p></li> <li><p>Do similar applications exist elsewhere that could help inform your design?</p></li> <li><p>Keep data access code out of your forms as much as possible - try to keep data access code in a separate class/DLL so that it is easier to maintain</p> <ul> <li>EDIT: as others have suggested, try to avoid having instances of ADO.Net connection and command objects scattered throughout the user interface - put all database connection code in one class/DLL so that it easier to fix/maintain/replace. I'd also suggest putting all your SQL query statements in a separate class or module for the same reason. *</li> </ul></li> <li><p>Follow any in-house guidelines that you, or others before you, have put in place.</p></li> <li><p>Keep maintainability in mind - someone after you may have to make changes. Use comments in code and give your objects (forms/variables/function names) sensible names</p></li> <li><p>Take regular backups of your code - put a copy on a network drive or USB drive every day</p></li> </ol>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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