I am working on project in which I have used visual c# as front end and SQL Server 2008 R2 Express for backend.
Now I know that SQL Server express database has a size limit is of 10 GB, so I have written the code for database backup when pick limit is reached and I empty the database once the backup is successful.
I want to know what will be best approach to restore the backup file so that my current applications backend (which I have emptied earlier) should not be disturb.
Is it okay if I restore the same in my current database, in that case I have question to ask does it affect my applications working, as my application is kind of real time and after every 15 min. interval stored some values in database.
Whether I need to write some other utility for seeing the old data..?
Every day around 50 MB of data is inserted into database, so it will take around 8 months to reach the pick size( as per my rough calculations). and as far as the nature of application is concern user will not going to use archive data frequently. please consider this and suggest me the approach.
thanks in advance..!!
Hope i got your question right, but consider the following suggestion for working:
one database ("Current DB") that stores the real-time data.
when it comes to a size, it is dumped (or copied mdf+ldf) to archive.
and stored with time stamps (FROM-TO).
When data is needed, the relevant mdf is attached as a new "offline" database.
(you can use a connection string to attach MDF file to an SQL Server.)
and use that connection instead of the live one.
The application can run smoothly on the On-line database.
while reading, loading etc...
is done from the temporary attached and detached database files.
Take a look at : Connection String to Connect to .MDF
for how to Attach a MDF to SQL Server instance.
If you enter the data in a whole new database server your old queries won't work on the new one. As SQL Express limit is not per database, but per database server.
You could create a new SQL Express Server, link your servers and create a query with a linked server ( How to create a linked server # msdn )
You will need to adjust your queries.
If you query your data now like this:
SELECT em.Name, em.Telefone FROM employees AS em
You need to refer the database too.
SELECT [server1\db1].dbo.em.Name, [server1\db1].dbo.em.Telefone FROM [server1\db1].dbo.employees AS em
for your current database, and
SELECT [server2\backup].dbo.em.Name, [server2\backup].dbo.em.Telefone FROM [server2\backup].dbo.em.Name
It is possible like this but I would not advise it. If you exceeded 10GB data already then you might have large tables. Each table at a linked server is copied completely to you server and could cause serious network traffic and takes quite some time to be executed.
I would think of getting the SQL Standard edition.
Related
I was wondering which one is the best way to replicate some data of a database to another.
I have a database in one computer and this one receives some transactions. I need to send this data to another server (in the same local network) but with a modified value (I need to add 11 years to a Timestamp value).
So I was looking for some options for my case, I can develop a windows service to do this but I don't know if the sql server replication can do this for me or if there is another option like some kind of magical trigger that can do that.
I'm using SQL Server 2005 on Windows Server 2003 R2.
This link should help you:
Selecting the Appropriate Type of Replication
Quoted summary from link:
Microsoft SQL Server offers three types of replication. Each type of
replication is suited to different application requirements. Depending
on the needs of your application, you can use one or more types of
replication in a topology:
Snapshot replication
Transactional replication
Merge replication
I personally would replicate the database (transactional) and then use log shipping to update the replicated database (on your second server) with the latest data changes (from the primary server) then use a stored procedure running as a sql agent job to update the fields you need.
I personally am not a fan of triggers as you can end up having triggers activating other triggers and something that takes milliseconds to run can take seconds and if you have large volumes of data that can be painful (I manage a system that has exactly this issue - soon to be replaced thankfully)
hope this helps and if you have some follow up questions I'll be happy to help.
I'm trying to understand how making a query to a .mdb file works.
Suppose the file is located on a share drive, PC2, I open it programmatically from PC1.
When I make a connection to a .mdb file, I assume no "instance" of MS Access is started on the PC2 (since it's a simple file server). Is this correct?
When I make a SQL query, does it have to copy the table locally, and run the query then return my results and toss away the table and any excess data?
What happens if I "order by" on a query? is the entire query returned, then locally ordered, or somehow ordered remotely?
I'm sure I have other questions, but I'm trying to understand how connecting to an MDB file works from a remote location. (we have a decent amount of latency where I am located, so a particular query can take 9 seconds, which in my case is unacceptable, I'm trying to understand how this is working and if it can be improved).
I'm running with c# in this case, I don't expect that should make much difference, but may in your response.
When I make a connection to a .mdb file, I assume no "instance" of MS Access is started on the [remote machine] (since it's a simple file server). Is this correct?
Yes. The application will be interacting with a copy of the Access Database Engine on the local machine, which in turn retrieves the information from the database file on the remote machine.
When I make a SQL query, does it have to copy the table locally, and run the query then return my results and toss away the table and any excess data?
Not necessarily. Depending on the indexing scheme of the tables(s) involved, the Access Database Engine may only need to retrieve the relevant indexes and then determine the specific pages in the data file that contain the records to be retrieved. In some cases it may need to retrieve the entire table (e.g., when a full table scan is required), but that it not always the case.
What happens if I "order by" on a query? is the entire query returned, then locally ordered, or somehow ordered remotely?
The Access documentation says that indexes will speed up sort operations (ref: here), suggesting that the Access Database Engine can retrieve the required rows from the remote file in sorted order.
Your instincts are correct, mdb/mde dbs are just glorified text files which must be processed locally. Here are some tips on network performance: http://www.granite.ab.ca/access/performancefaq.htm
But since SQL Server Express is free, there is almost no excuse for not migrating, especially since Access has a tool to manage that for you. In a low volume multi-user environment (2-10 for example), MS Access can work ok, but for enterprise solutions where a higher volume of users and/or transactions is in any way possible, you are dicing with disaster.
To add to Gord's answer...
Access databases are accessed through Windows file page locks. My understanding was that Microsoft added this page locking specifically for use by MS Access (but is also available for any file through the Windows API).
Because the instance is local and collisions and conflicts are handled through file page locks, client-server contention is an issue. Access has known issues here. It's why one should switch to SQL Server Express (also free) whenever possible. But, yes, MS Access has a certain level of convenience; SSE has a bigger footprint and a far less friendly GUI
All desktop databases have client/server issues. Gord's answer matches my knowledge. The point of indices is to reduce the amount of table data that needs to be pulled locally. Pulling the index is a relatively small task in comparison to the table data. This is standard index optimisation, although I would say it is even more important for desktop databases due to the remote data and, ugh, file paging.
In general the Access (JET) engine does NOTHING remotely. It's all file data grabs and executed locally in in the local MSA/Jet engine. You know this because the engine is installed locally and doesn't have to be installed on the file host. It is, however, a convenient quick and dirty way of dispersing processing loads. :)
I'm developing an app that happens to have some records that need to be updated pretty often. I wanted to avoid deploying SQL Server on the client pc so I read a lot and thought a local .mdf file could be a solution (not so sure now if it's possible to avoid deploying SQL Server, after a few days I'm just realizing I could be miles away from right LOL).
Also, reading, I found there was a way to bind controls to data by visually moving objects from the Data Sources window, so I thought I was going to save a lot of time, but in the end I just got really confused because I couldn't get to actually write to the database file and information currently available seems to be pretty unspecific and works/doesn't for a lot of versions and flavors of VS (i.e. WPF, Windows Forms, vs 2008, vs 2010, and even older .NET framework versions), so I thought someone here in stackoverflow forums might have these things pretty clear.
So, I have some questions I believe will clear out my confusion (and anyone coming across this problem):
Can a .mdf file actually be used without a SQL Server installation?
VS is sometimes confusing, it offers to create a local database file without requiring a SQL Server install, I guess I take a lot of things for granted as I'm not an experienced .NET programmer.
If it's not possible. Is there any other way to avoid deploying SQL Server on the client, and is it a valid concern?
Maybe I shouldn't be worried about not deploying a SQL Server install on the client machine?
Can I get the fancy data bound controls to work with some similar kind of 'automagical' update call that writes changes directly to the database?
There seem to be two ways of managing the database using the app, and, of course, I would like to do it this way and just get those data bound controls to work, as the database is huge and there is not much to process in the way, just store.
Does the DataSet contain a temporal copy of the database?
I have a Database.mdf and a DataSet.xsd and, after searching for reference, I still don't know exactly what's up with these two guys.
No. When you create a new item in your project, the Server-based Database template creates an MDF file and requires a SQL Server Express instance to be installed on all clients.
The Local Database template creates an SDF file, which is a SQL Server CE database. Despite the name, SQL Server CE is a completely different product to SQL Server (Express). SQL Server CE doesn't use a server so you can either install it on the client or just deploy the required DLLs with your app.
Run the Data Source wizard and select your data source. The rest is done for you, as long as you select a supported data source. You can use SQL Server Instance, SQL Server Express File, SQL Server CE or Access out of the box. You can also support Oracle, MySQL and others with downloads from third-party providers.
The MDF is the actual data file, the same as big SQL Server uses to store data. The XSD is the XML schema definition for the DataSet, which is a class like any other. When you retrieve data from the database you use a table adapter, which is an instance of a custom class generated by the Data Source wizard. That table adapter wraps up the standard ADO.NET connection and data adapter objects that you would use yourself if you were not using the wizard. The Fill method of the table adapter populates a DataTable in a DataSet, which are also custom classes generated by the wizard that inherit the standard DataTable and DataSet classes. Once you've made the desired modifications to the data, you call Update on the table adapter to save the changes back to the database. If your controls are bound then populating the DataTable will automatically populate your controls and making modifications in your controls will automatically modify the data in the DataTable.
I have written certain code to take the Backup of a Database, the application will take the Database Backup automatically at the time Specified. Now, I want some help to take Successive Backup of the Same Database which was taken previously and dont want to take Complete Database Backup again and again. Can any one Help me.
How to make incremental backups with MS Sql Server in c# : http://www.mssqltips.com/tip.asp?tip=1849
I need to copy several tables from one DB to another in SQL Server 2000, using C# (VS 2005). The call needs to be parameterized - I need to be able to pass in the name of the database to which I am going to be copying these tables.
I could use DTS with parameters, but I can't find any sample code that does this from C#.
Alternatively, I could just use
drop table TableName
select * into TableName from SourceDB..TableName
and then reconstruct the indexes etc - but that is really kludgy.
Any other ideas?
Thanks!
For SQL Server 7.0 and 2000, we have SQLDMO for this. For SQL Server 2005 there is SMO. This allows you do to pretty much everything related to administering the database, scripting objects, enumerating databases, and much more. This is better, IMO, than trying a "roll your own" approach.
SQL 2000:
Developing SQL-DMO Applications
Transfer Object
SQL 2005:
Here is the SMO main page:
Microsoft SQL Server Management Objects (SMO)
Here is the Transfer functionality:
Transferring Data
How to: Transfer Schema and Data from One Database to Another in Visual Basic .NET
If the destination table is being dropped every time then why not do SELECT INTO? Doesn't seem like a kludge at all.
If it works just fine and ticks all the requirements boxes why create a days worth of work growing code to do exactly the same thing?
Let SQL do all the heavy lifting for you.
You could put the scripts (copy db) found here
http://www.codeproject.com/KB/database/CreateDatabaseScript.aspx
Into an application. Just replace the destination. To actually move the entite database, FOLLOW
http://support.microsoft.com/kb/314546
But remember, the database has to be taken offline first.
Thanks