So, my client say they want to manage some of the information on their website in a separate access file and upload that from time to time. It seems a reasonable request so I implement an uploader that backs up the current file for safety's sake.
The problem arises that they are on a carrier pigeon slow connection and the upload times out, or someone accesses the website while the file is being overwritten, or the stars are aligned just so and any part of the site that gets data from the ms-access file falls over until the web.config file is re-copied across, causing the website to reset.
Is having a file that doesn't get overwritten ever and the following "redundancy" / "failover" approach epic fail in the making, or have I almost-but-not-quite got a working solution here (obviously they're still getting errors under afore-mentioned special circumstances, again unrepreducible by local testers)
private static OleDbConnection conn;
public static OleDbConnection GetAccessConnection()
{
if(conn == null)
{
string connstring;
try
{
connstring = ConfigurationManager.ConnectionStrings["AccessConnectionString"].ConnectionString;
conn = new OleDbConnection(connstring);
ExecuteNonQuery("SELECT TOP 1 * FROM MyTable");
return conn;
}
catch
{
connstring = ConfigurationManager.ConnectionStrings["AccessConnectionString1"].ConnectionString;
conn = new OleDbConnection(connstring);
ExecuteNonQuery("SELECT TOP 1 * FROM ServiceProviders");
return conn;
}
}
return conn;
}
with
<connectionStrings>
<add name="AccessConnectionString" connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source={My File Path};Persist Securi开发者_开发问答ty Info=False;"/>
<add name="AccessConnectionString1" connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source={My Backup File Path};Persist Security Info=False;"/>
</connectionStrings>
If insistent upon staying with an Access DB, then here's one idea you could try that would dramatically speed up the replacement process, therefore minimizing downtime, corruption, or lock-out issues.
Create a new Access DB file (A), and within it create table [links] to all of the tables in your original database (B). So now your web app will reference the new database, which will appear to have all of the same tables as before, except they will be table links to your real database (B).
When it comes time for a database switch, simply copy the new database (C) up to the server. Then open database (A) and relink the tables to point to database (C). The relinking process will take only a few seconds, and involves no data movement, and your web app won't know anything changed.
I'm not suggesting this is a good practice, but it may help you in the short term until you can entertain the idea of moving to SQL Express or something similar.
Just a thought ;-)
精彩评论