Sometimes I think I should be a tester for developer tools. For some reason I have the uncanny knack of stumbling onto the most obscure bugs in Visual Studio.
I am currently trying to learn Microsoft Sync Framework, and decided (after watching a good video on how to do it) to set up an ADO.Net Sync Services Local Database Cache. I went through the process step by step, the only 2 differences between my environment and the one demonstrated in the video was that I was running SQL Server 2008, and I was using the AdventureWorks2008 database.
The procedure I followed was this…
- Create a new Winforms Application
- Add A new Local Database Cache (this starts the wizard)
- select the AdventureWorks database
- Select the Production.Products, Production.ProductDescription, Production.ProductPhoto tables to add to the cache.
- Click OK.
Everything else I left as the default configuration. The result:
So I figure it’s something to do with my environment. I spent about half an hour Googling and looking at forums before I decided that I must be the first person ever to hit this bug. Next I tried to see if it was because of something in my environment, I checked my setup
Windows 7 64 bit; SQL Server 2008 SP1; Visual Studio 2008 SP1; Sync Framework 2.0 x64;
The only thing I could think might be an issue was the Sync Framework 2.0 x64, so I uninstalled and installed the x86 version. Still the same problem.
I then opened SQL Profiler and tried to see if anything was obvious there, but concluded that it was all OK (I later discovered that I didn’t look closely enough at this).
I then cracked open the wizard dlls in reflector to see if there was any help there, but alas, theat was pretty much a dead end too.
I even posted an article on the Sync Framework Forum.
Frustrated, I decided that it had to be my own environment that was causing the problem, so I set about creating a virtual environment on GoGrid. Once I had managed to get everything installed, I tried just the Production.Products table this time, and got the exact same error.
I then tried creating a completely new table in a completely new database, and, surprise surprise, it actually worked… well, almost. It got past the wizard, but the code it generated would not compile. It appears that I stumbled on yet another bug in the Sync Framework wizard, if you use a table called “SyncTable”, the generated code is broken.
Encouraged by the “success”, I pressed on undeterred. I finally got everything working by creating a table called “MyTable”.
Not satisfied that I had made it work (finally), I decided to try and track down the bug. After about an hour or so of playing around and not having any success, I finally cracked open SQL Profiler again and found that the last statement executed before it died when trying to create a local database cache for the Production.Product table was the following
SELECT * FROM [Product]ion.[Product]
Obviously the code that works out the schema and table name needs some reworking.