I`m using SQL Server Compact (SQL CE) together with sync framework. However the sync framework creates some system tables when calling the CreateSchema() method of the SqlCeClientSyncProvider (e.g. __sysSyncArticle, __sysSyncSubscription, ...).
I'm not able to delete these tables with SQL statements within Visual Studio (states that "drop table is not supported") and when trying to create a SqlCeCommand I get a message that the specified tables do not exist.
What does it take to delete SQL CE system tables programmatically?
Joachim, You need to work with the Sync Framework on this, not against it. The point of the database is to track the sync metadata. If you want it to be a different replica (different anchor, client id, etc) then set it up as a different replica.
I suggest that you look at the new MSF 2.0, specifically the Provisioning and Management APIs. They seem to provide more of the flexibility you need.
Sync Framework v2
Related
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
Is there a way to use Microsoft Sync Framework without implementing the required schema changes ('_tracking tables'). Basically, I am faced with the task of Syncing two SQL Server 2008 databases, one of which is a legacy db that we cannot make any schema changes to.
Would it be possible to store the additional tables required for each database in a separate database?
e.g. I have 3 tables that we need to sync (Staff, Customer & Sales), normally we would just add the three additional tracking tables, but this isn't possible. Instead, can I have a separate database with the required tracking tables (Staff_tracking, Customer_tracking, Sales_tracking) and somehow point the sync framework to this new db??
Any help is appreciated, and a code example would be super!
Since you are using SQL 2008 as the database, just turn on change tracking and let SQL Server track the change tables for you internally without having to change the schema of the actual client database. MSDN explains it nicely in this article. About half way down you will see the following:
SQL Server 2008 has introduced a new alternative method for tracking
changes called SQL Server 2008 Change Tracking. The concept behind
change tracking is that an administrator marks certain tables to be
monitored for changes. From that point SQL Server 2008 keeps tracks of
any inserts, updates, or deletes that are made. When a remote
“requestor” requests changes, SQL Server 2008 will provide all of the
changes that have occurred since the last successful download as
specified by the requestor. The Sync Framework database
synchronization providers have been built to take advantage of SQL
Server 2008 change tracking and provide the following advantages for
an OCA environment:
No schema changes are required to be able to track changes.
Assuming you are using the standard Microsoft synchronization providers, change tracking support is included by default.
I have the pleasure of using SyncFx v.2.1 on an application. The client side presently uses SQLCE and the Server side uses Server 2008 r2. I am using a SyncFx proxy and host the server SyncAdapterBuilder code in the WCF service. The client has the SyncAgent and SyncTables and it works fine. I am using the integrated SQL Change Tracking in lieu of the coupled (aka custom / scoped) change tracking because I am not permitted to modify existing schema.
So my issue is that the requirements for the system have changed and I am required to use SQL Express on the client in order to support stored procedures.
Why not merge replication? The requirements also prohibit modification of the schema or the use of triggers. In fact the original version of the app used merge replication with SQLCE before moving to SyncFx for SQLCE.
So how is this done? I've read a lot of conflicting information and I can only assume that this is in response to the ever evolving versions of SyncFx. There are no direct example of how SQL to SQL Express with Change Tracking on both is accomplished. Plus I am trying to transition from a functional SQLCE implementation to Express with as few changes as possible. The client is already capable of using either type of DB, it is just the current sync process that needs to change.
Here is what I've found, but have not had success. I've read every StackOverflow response on the matter and am still not finding a way to do this that actually works.
Database Sync:SQL Server and SQL Express N-Tier with WCF : This MS example works fine with the SyncOrchistrator but provisions side tracking tables and triggers. I was not able to modify this in such a way that change tracking could be used on the client and server.
Sync framework with SQL Server 2008 Change Tracking : StephaneT suggests here that simply by using the normal SQLCE approach with the SQL Express sample sync provider and SyncFx 2.0 techniques only client side table modification would be required. Unfortunately all links to this sample SQL Express provider seem to be removed and other posts from JuneT and even Liam Cavanagh on MSDN suggest moving forward with the new official SqlServerProvider instead of a customized version of the DbServerProvider. Problem is there are no sample implementations of this anywhere and I haven't been able to figure it out through trial and error.
Syncing SQL Server 2008 Databases over HTTP using WCF & Sync Framework : Raj gives the best example (simple and easily translated to SQLCE processes) unfortunately it also uses the SqlExpressClientSyncProvider that seems to have evaporated from the internet. It also requires an anchor table to track the clients, I think I can get away with that as I am not allowed to modify schema on "existing" tables.
So any examples out there that can help me. Essentially I want to port the existing functioning SQLCE SyncFx via proxy with integrated SQL Change Tracking using a SyncAgent to a version that works for SQL Express without changing existing scheama or using triggers. I should also mention that I use filter parameters heavily as there are 150+ tables in the replication and they would be extremely large without filters. I had read some references that said the SqlExpressClientSyncProvider didn't support filters, but this is impossible for me to verify since I can't find a reference to that code that is still good.
Maybe there is a refresh of Raj's example that uses SqlServerSyncProvider
Thanks in advance to anyone that can point me in the right direction!
check out this link and you might still find some of the download links in the comments area working: http://www.8bit.rs/blog/2009/05/debugging-sql-express-client-sync-provider/
take note that even the sample SqlExpressClientSyncProvider uses triggers to track the deletes in the tombstone tables. likewise, you need to have columns in your table to track when a row has been inserted or updated (datetime or timestamp columns).
with regards to filtering, you can easily modify the queries in the adapter to include a filter clause.
the newer SqlSyncProvider does not support Sql Change Tracking as it implements its own tracking mechanism. the newer providers works in a peer-to-peer scenario so its tracking as well from which replica a particular change has come from.
I just started to use LINQ-to-SQL, so my problem may be trivial.
We have a central database running on SQL Server 2005. There are distributed desktop .NET 4 applications which save measurement data into a local SQL Server Compact database. These local database (SDF) files are regularly transported to the server, where they are imported into the central database using SqlBulkCopy.
The distributed desktop applications use LINQ-to-SQL to handle data and to create their local SDF database. The ORM is currently done by a manually written DataContext subclass, compiled as a separate library, which contains a nested class for every table of the central database. I wrote the DataContext subclass by hand simply because I wanted to avoid code generators before I more-or-less understand how LINQ-to-SQL works.
The central database is simple at the moment, but it will structurally expand soon, by adding new tables and adding new versions of existing tables. The problem is, it would be nice to automate the generation of the DataContext subclass. In an ideal situation, this could be done as part of the daily build process. This way after the database team changes the database, the application developer team would get the new version of the ORM library. (Old code would not break, since every old table would stay in the database. Old versions of the tables will be deleted only when none of the distributed application versions use them.)
So my question is, what is the best way to generate a DataContext subclass for an existing database? I would prefer a command line tool or an API. Thank you for your help in advance!
For some integration tests I want to use LINQ to SQL to drop/re-create the test database. I've had this working fine before, however in this project the database is split up into several schemas.
When I try to run the ctx.CreateDatabase() command I'm getting this exception:
The specified schema name "xyz" either
does not exist or you do not have
permission to use it.
The login I'm using to do this has the role dbcreator - Does it need further permissions? Surely a login with persmissions to create a database should be able to create everything contained in that database also?
Update:
Since it looks like there isn't a solution to this problem using LINQtoSQL, does anyone have recommendations of any similiar tools to generate a db that are preferably free? Ideally I don't want to have to muck about hand writing sql build scripts.
From what I've read, the CreateDatabase() method is limited in what it can reproduce of the original database. It won't recreate things like triggers and check constraints, and I'm guessing it doesn't create custom schemas either. You may want to look into creating the database using a SQL Server .mdf file instead to work around this issue. See this blog entry for more details on some of the limitations of CreateDatabase().
I generally do this sort of work in NAnt to create, initialize the database, create users, add logins, etc....and also roll back capabilities. I have written on this topic quite a bit if you are interested:
Build automation with NAnt
Continuous integration with CruiseControl.NET
I will have to see if I can get LINQ to SQL to work in the way you are trying to use it...that sounds like what we used to do with NHibernate.
The dbcreator fixed server role grants you the permission to create a database. If you create a database, you are the dbo of said database and as dbo you have absolute power in the database, includding the power to create, alter and drop any schema and any object contained in any schema.
the problem with LINQ's CreateDatabase() is not permission, is code quality. The generated SQL code simply does not create the needed schema, so the Create table statements fail because the schema does not exist.
Your best choice, if you can afford it, is to add a VSTS Database Edition GDR R2 project to your solution and declare all your database objects in the Database Edition project (part of your solution). You'll be also getting the added benefit of storing all your database objects in a proper source control solution. The output of the Database project would be a .dbschema file containing the definition of your database. At deployment time (test or real) you would run the VSDBCMD Deployment and Schema Import tool to import your .dbschema into the target server. The tool is capable of doing initial deployment of your schema, as well as further upgrades (deploy only differences). The VSDB solution would allow you to controll all your database objects: tables, indexes, views, schemas, field contraints, table constraints, triggers, procedures, users, permissions, logins etc etc. It really covers all the objects that can be defined in SQL Server.
Actually LINQ to SQL does support schemas, but not every Sql Server edition does. To enable CreateDatabase() to generate them the DataContext must be aware that the target database does support them. It can be done by setting the provider on the DataContext:
[Provider(typeof(Sql2008Provider))]
public class CustomDataContext : DataContext {
...
}
Your user also requires db_dlladmin for that database.
I would definately look at Entity Framework, which I am beginning to look into these days. It's an OR/M, and will most definately suit your needs, and alot more once the next version is released.
Entity Framework is also a brain-child of Microsoft and can be found here: http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx
One thing to remember between LINQ to SQL and LINQ to Entities is that you are programming against a model, and not the database.