locked
SqlCe 3.5 RRS feed

  • Question

  • Hi All,

    I'm having an odd problem with the format of the metadata store that is being generated.  When I add a connection to the generated metadata store I'm informed that it was made with a previous version of SqlServerCe and I have to update it to a 3.5 format database.

    Reading through the docs it apparently seems to use a 3.5 format database which is really confusing.

    What's more confusing is that I only have SqlCe 3.5 on my dev machine so how is it making a pre 3.5 version database in the first place!

    When I try to open the store like:

    SqlMetadataStore _store = SqlMetadataStore.OpenStore(System.IO.Path.Combine(metaDataLocation,metaDataFile), CultureInfo.CurrentCulture); 

    It throws an engine exception.



    jammer
    • Moved by Max Wang_1983 Thursday, April 21, 2011 5:41 PM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Friday, March 6, 2009 7:37 PM

Answers

All replies

  • I've just done a manual upgrade on the database and now I'm seeing this error:

    A storage engine operation failed with error code 28609 (HRESULT = 0x80004005, Source IID = {0C733A8B-2A1C-11CE-ADE5-00AA0044773D}).

    It seems that 28609 error is related to Case Sensitivity on the database.  This gets weirder by the second!  Case sensitivity was a feature added in SqlCe SP1 I think, which is the version I have installed ...

    Any help with this mess would be great if there is any.  Searching google doesn't seem to offer anything.

    Thanks!

    jammer
    Friday, March 6, 2009 7:48 PM
  • I'm now also seeing this error code 0x80040E21.

    This is all rather confusing and frustrating to be honest.

    Anyone with any ideas at all would be great.  I've tried all sorts of things to fix this.  If I run CreateStore() all is fine ... I can then also run OpenStore() on the same store and I get an SqlMetaDataStore object.  But if I create a FileSyncProvider the store generated by this cannot be opened with a SqlMetaDataStore ... making the metadata completely inaccessible.

    It seems like the two object internally use different SqlCe versions.  Could this be related to me having two different versions of System.Data.SqlServerCe in my GAC?  I've got version 3.5.0.0 & 3.5.1.0

    I've tried removing 3.5.0.0 but it seems like its required by other things I have installed and I don't want to break anything trying to fix this problem.

    Any information would be really appreciated.  I've tried everything I can think of to fix/investigate this.  Its really frustrating since the Sync Framework seems like a great tool but its near on useless if I can't reliably query the metadatastore.

    Thanks in advance ...

    jammer
    Saturday, March 7, 2009 10:32 PM
  • Hi -

    I am sorry if the documentation is pointing to us using a SQL CE 3.5 database. That is not the case - we are using a version of the SQL CE database but we are building our own binaries for this and redistributing it with out Sync Framework so you are not going to see this installed on your box. If you upgrade the SQL CE database manually like you did - you are going to find that the Sync Framework is not going to be able to open the file either.

    What is your scenario and why are you trying to open a connection to the file yourself?

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Monday, March 9, 2009 9:36 PM
    Answerer
  • Hi Deepa,

    No problems, I think I may be reading into it being a SqlCe database because the upgrade worked! ;)

    Basically my requirement for trying to open the db is because I don't ever want to actually syncronize two folders (using the FileSyncProvider).  I've written an database application that stores information about specific locally stored file types.  The problem my users then face is over time the database falls out of sync with their local file system and then needs re-scanning to update it.

    A friend pointed me in the direction of the sync framework.  After playing around with it a bit using the standard model of syncing two file systems I then moved onto looking at using for my specific need.  I have been using a single replica and running the DetectChanges() in order to build the metadata.  I was then looking to access the metadatastore to discover the changes to then apply to application database.

    This is where the troubles started!

    Basically, at this point in time I'm not sure that the sync framework is set up for this kind of task.  Do you have any ideas/info on how I might go about getting the sync framework to provide this kind of functionality?

    Thanks for your time.

    Regards,

    James.

    jammer
    Monday, March 9, 2009 10:15 PM
  • Hi - If I understand your scenario correctly - you are not using the Synchronizing ability of hte framework but are depending only on the FileSyncProvider being able to detect changes for you? If that is the case - you are right the sync framework is not intended to be used like this and we do not support non-FileSyncProvider connections to the metadata store.

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Tuesday, March 10, 2009 6:56 PM
    Answerer
  • Hi Deepa,

    Thanks for this info!

    Are there any plans to add this kind of functionality in the future?  This would be a seriously cool feature for the framework.  Considering all the stellar work that has gone into the various internals of the framework it would be awesome to allow this kind of monitoring.

    Regards,

    jammer
    Tuesday, March 10, 2009 8:23 PM
  • Hi -

    We will keep this in mind for future enhancements but we really are focusing on the synchronizing ability - not exactly on the detecting change on the FileSystem part for now :)

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Wednesday, March 11, 2009 7:35 PM
    Answerer
  • Hi,

    Indeed it makes sense to primarily concentrate on sync functions, seems this new function would only require augmentation of the framework since a lot of the leg work is already there.

    Thanks for your time deepa, much appreciated.

    Regards,

    jammer
    Thursday, March 12, 2009 3:30 PM
  •  Hi,

    Of course you could write a matching sync provider to sync with you database.  At the moment our (managed) FSP doesn't play that nice with other providers but we are working on that.  But you could easily write two Simple Providers, one to replace the FSP and one to sync to your DB.

    Check out the Simple Provider API in our latest CTP:

    http://www.microsoft.com/downloads/details.aspx?familyid=A3EE7BC5-A823-4FB4-B152-9E8CE9D5546F&displaylang=en

    And the sample here:

    http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=sync&ReleaseId=1713

    -Jesse
    • Marked as answer by findjammer Thursday, March 12, 2009 8:51 PM
    Thursday, March 12, 2009 6:29 PM
  • Hi Jesse,

    Thanks for these!  I'd only gotten the previous versions of the samples for V1.  I'll have a look at these samples now ...

    Thanks,

    jammer
    Thursday, March 12, 2009 8:08 PM
  • Hi Jesse,

    For the provider that would replace the FSP would you recommend using an instance FileSyncProviderClass(); to detect the file system changes and then wrap that in my own provider?  Or would you create a custom provider from the ground up?

    Do both providers need to use the same metadatastore format in order for the sync to work correctly?

    Cheers,

    jammer
    Thursday, March 12, 2009 8:55 PM
  • What I would recommend is waiting for our next CTP which will provide better support for writing a provider that can sync with the FSP :).  However, if you check out the SimpleProvider apis you'll find that it's not too difficult to get a custom provider up and running.

    No both providers do not care about eachothers metadatastore format.  Providers must only agree on 2 things to sync with each other (two MSF providers that is, implementing MSF apis):

    1) Id formats (formats of the unique global ids identifying items)
    2) transfer interface - the interface to pass the data between the two

    If you use the Simple Provider api you will not care about metadata at all, nor will you have to care about id formats - it's all taken care of for you.

    -Jesse
    Friday, March 13, 2009 12:27 AM
  • Jesse L - MSFT said:

    What I would recommend is waiting for our next CTP which will provide better support for writing a provider that can sync with the FSP :).  However, if you check out the SimpleProvider apis you'll find that it's not too difficult to get a custom provider up and running.

    No both providers do not care about eachothers metadatastore format.  Providers must only agree on 2 things to sync with each other (two MSF providers that is, implementing MSF apis):

    1) Id formats (formats of the unique global ids identifying items)
    2) transfer interface - the interface to pass the data between the two

    If you use the Simple Provider api you will not care about metadata at all, nor will you have to care about id formats - it's all taken care of for you.

    -Jesse


    I'm glad you said that and not I!! :)

    Thanks for this info Jesse, I'll watch with anticipation for the next CTP.  Any rough ideas on ETA on that?

    I've been looking over the APIs and will continue to do so, a better understanding of key bits is very much needed either way.

    Off to learn ...

    Thanks for your time.

    Regards,

    jammer
    Friday, March 13, 2009 5:56 PM