Provisioning and Deprovisioning

[charristti]

Using 1.0.0-beta-1517 with Net8.02, MS Sql Server Express 2017, with Sql Change Tracking

1. When provisioning a scope, occasionally getting scope_info records with sync_scope_schema and sync_scope_setup both set to null. Deleting the records and reprovisioning usually works.
2. When deprovisioning a scope the table property Change Tracking is being set to False even though there are other scopes still referencing the same table.

[Mimetis]

When provisioning a scope, occasionally getting scope_info records with sync_scope_schema and sync_scope_setup both set to null. Deleting the records and reprovisioning usually works.

Not sure I understand.
Can you elaborate a little bit ?

When deprovisioning a scope the table property Change Tracking is being set to False even though there are other scopes still referencing the same table.

DeprovisionAsync is .... deprovioning.... regardless any others scopes.
IF you don't want to deprovision a table, check the others scopes before, to see if the table is used somewhere else ?

That's being said, this is something we can also do in the framework

[charristti]

Thank you for your response. I have changed the settings when deprovisioning to no longer remove the tracking file. I have not been able to reproduce the first issue since I added some additional logging to try and isolate the issue Thanks again.

…

On Mon, Feb 26, 2024, 6:28 PM Sébastien Pertus ***@***.***> wrote: When provisioning a scope, occasionally getting scope_info records with sync_scope_schema and sync_scope_setup both set to null. Deleting the records and reprovisioning usually works. Not sure I understand. Can you elaborate a little bit ? When deprovisioning a scope the table property Change Tracking is being set to False even though there are other scopes still referencing the same table. DeprovisionAsync is .... deprovioning.... regardless any others scopes. IF you don't want to deprovision a table, check the others scopes before, to see if the table is used somewhere else ? That's being said, this is something we can also do in the framework — Reply to this email directly, view it on GitHub <#1138 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH7XOLYNVMCM7LK5XSFZ3GLYVULCFAVCNFSM6AAAAABD2ZG55GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVGUYTEMZXGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>