Is it possible to create database files that are independent from any SQL Server engine on the fly? The thing is that we want to create one database file per user in our application, and we want that database to be stored in the user's directory but we don't want to connect to it through SQL Server. Prety much like an sdf file, but instead of App specific, User specific.
So what we want to do is that every time a user is created in the app, generate their folder, and generate the database schema, which will be populated later.
Sounds like you're looking for SQL Server Compact. You can create any number of these databases at runtime and place them anywhere you want.
Sounds like you really want a combo of "Access" and the Jet engine.
It meets the database in a single file requirement and is reasonably performant for single user access.
Another possibility would sqlite, which is IMHO a better database but support for C# seems immature.
You can also have empty database file stored and each time a new user is created make a copy of that empty database file into the user folder. This way the schema will be there from the empty database file (it is like a template or a model database from the SQL Server).
SQL Server Express/Compact with smo to programatically create your db.
Related
I'm looking for good ideas how to copy the whole Schema from a SqlAzure Database to another SQL Azure Database. (Tables, Data)
Goal:
I'd like to use a "template" Database seperated with Schemas. Each schema represent another kind of "template" data. On creating a new database (ef6, c#) I want to add the selected Template-Data...
What I tried:
=> Creating bacpac and try to import this.
Works great, but you can only import to new database, not to an existing database.
=> Creating scripts
Works but painfull.
Anyone can give me an advise ?
Have you tried using the schema compare feature in the SQL Server Data Tools available for Visual Studio? It will allow you to compare the complete schema of your template database and your target database. Once it has done the diff, you should use Group By > Schema to organize the results which will then enable you to selectively apply the changes for one or more specific Schema(s) to the target database. For more info on SQL Server Data Tools see https://msdn.microsoft.com/en-us/mt186501
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.
Is there a way I can write C# code to write the structure of an SQL table and the contents of its data to text files? So far I figured out how to use BCP to copy the data, but I'm not sure how to copy the table creation script using C#.
Am I going down the right path or is there a better way to do this? I basically want to automate the table backup scripts that can be created in SQL server. The ideal output would be two sql files. One that creates the table and one that populates the data. BCP data isn't in SQL format so you can't just execute it in SQL server (which is what I want, this just will make it more user friendly for the people I work for).
You can do this with SQL Database Management Objects (SQL-DMO).
An example of scripting objects is here: http://msdn.microsoft.com/en-us/library/ms162153
As stated in the title, how can I programmatically create a SQL Server CE 4.0 from a remote SQL Server?
I want my application to allow users to delete the .sdf and create a new one based on the new remote database schema when there is a database schema update. And then download relevant data for offline use.
I already read up about the SqlCeEngine part, but I am not good at SQL Server CE queries - seem to give many syntax errors when trying out in Management Studio.
I also tried Microsoft Sync Framework Snapshot synchronization but it feels too bulky and the Local Cache Database modifies my database schema and generates a lot of junk I do not need. Maybe a lower level solution like querying information.schema or something may work better?
Checkout DMO. Using managed code, you can enumerate objects like tables, columns on the sql server side.
http://msdn.microsoft.com/en-us/library/aa174487(v=sql.80).aspx
Here's a tutorial to get you started:
http://www.codeproject.com/KB/database/SMO_Tutorial_1.aspx
Concerning the data, one option is the bcp utility
http://msdn.microsoft.com/en-us/library/aa337544.aspx
Those are good starting points if you want to extract and create a new database. For mirroring/sync, probably not a good path. If it's read only data on the client and you jst want to update the local data, then you can just extract again and throw away the old 'data cache'
You can use my scripting API and command line tools to do this: http://exportsqlce.codeplex.com - see for example this blog post: http://erikej.blogspot.com/2010/02/how-to-use-exportsqlce-to-migrate-from.html
This may be a more up to date way using SQL only:
SELECT * FROM INFORMATION_SCHEMA.COLUMNS
I am trying to replace a DTS access exporter package with a exe we can call from our stored procedures (using xp_cmdshell).
We are in the middle of a transition between SQL 2000 and SQL 2005, and for the moment if we can not use DTS OR SSIS that would be the best options.
I believe I have the following options:
Using a SQL data reader to read SQL records, and using ADO.net to insert the read records into Access.
I have implemented this and it is WAY too slow. This is not a option
Setting up Linked tables in access, then getting access to pull the data out of sql.
If anyone has any experience in doing this I would be grateful for some code examples or pointing out some resources?
If there are any other options for transferring large amounts of data from SQL into a Access database that would be awesome, but performance is a big issue as we can be dealing with up to 1mil records per table.
Have you tried this?
Why not creating a linked table in Access, and pulling data from Sql Server instead of pushing from Sql to Access ?
I've done plenty of cases where I start with an Access database, attach to SQL Server, create a Create Table or Insert Querydef, and write some code to execute the querydef, possibly with arguments. But there are a lot of assumptions I would need to make about your problem and your familiarity with Access to go into more detail. How far can you get with that description?
I have ended up using Access interop, thanks to le dorfier for pointing me in the direction of the import function which seems to be the simplest way..
I now have something along these lines:
Access.ApplicationClass app = new Access.ApplicationClass();
Access.DoCmd doCmd = null;
app.NewCurrentDatabase(_args.Single("o"));
doCmd = app.DoCmd;
//Create a view on the server temporarily with the query I want to export
doCmd.TransferDatabase(Access.AcDataTransferType.acImport,
"ODBC Database",
string.Format("ODBC;DRIVER=SQL Server;Trusted_Connection=Yes;SERVER={0};Database={1}", _args.Single("s"), _args.Single("d")),
Microsoft.Office.Interop.Access.AcObjectType.acTable,
viewName,
exportDetails[0], false, false);
//Drop view on server
//Releasing com objects and exiting properly.
Have you looked at bcp? It's a command line utility that's supposed work well for importing and exporting large amounts of data. I've never tried to make it play nice with Access, but it's a great lightweight alternative to DTS and/or SSIS.
Like others have said, the easiest way I know to get data into an Access mdb is to set things up in Access to begin with. Roughly speaking:
Create linked tables to the SQL data you want to export. (in Access: File --> get ecternal data --> link tables) This just gives you a connection to sql server.
Create a local table that represents teh schema of the data you want to export. (on the tables tab, click the "new" button and follow your nose).
Create an Update query that selects data from the linked tables (SQL Server) and appends rows to the local table (access mdb).
On the macros tab, create a new macro that executes the query you just created above (I can't recall the exact "action" to use, but it's something like OpenQuery or RunQuery); name the macro "autoexec", which will cause it to automatically run when the mdb is opened.
Use a script (or whatever) to copy and open the mdb when appropriate; the autoexec macro will kick things off and the query will copy data from SQL server to the mdb.