Comments
Sort by recent activity
The "CREATE TABLE ... AS FILETABLE" syntax is the script that SSMS generates. That's the way I originally generated the OrganizationFile table. It was and is a standard FileTable from the beginning. None of the red-gate products generate this script, nor should they. I suspect that the reason is because the exact names of essential elements of the FileTable are hidden (and inconsistent) when that command is used. Specifically the names of the various table constraints and self-referencing foreign key appear to be dynamically generated with that command, so it's not surprising that the comparison engines treat them like conventional tables. In fact, I would expect just that so it can accurately compare the individually named components.
Have you actually tried reproducing the issue? It should be simple to reproduce with these steps:
1) Create a DB with a single file table generated by using the "CREATE TABLE ... AS FILETABLE" syntax in SSMS.
2) Create a SQLConnect project and sync it to this new database.
3) Save the SQLConnect project in Subversion
4) Use SQL Source Control to put the new database itself in source control using the same subversion repository URL as the SQLConnect project.
5) Note that SQL Source Control shows the database (specifically the file table) as being out of sync when it really isn't.
Are you able to reproduce that scenario?
Let me know if you need more info from me.
Thanks,
David / comments
The "CREATE TABLE ... AS FILETABLE" syntax is the script that SSMS generates. That's the way I originally generated the OrganizationFile table. It was and is a standard FileTable from the beginning...
Thanks for the reply. The only reason that this issue came up is because my SQL SourceControl and SQLConnect are using the same SVN repository and the same database, but SQLConnect says the File Table is in sync with the project and SQL Source Control says they are out of sync. That's the real issue I'm trying to resolve. I am aware of the fact that the data shown in the UI is not exactly the same as used by the comparison engine. That's bit me before, so you're right, the data I've shown is from the respective UIs. I'll leave it for you to find out why the the underlying comparison engines disagree in the different products. If it's any help, I'm using the default comparison options in all applications. If there's a way I can tweak the SQL SourceControl comparison options so that they are the same as SQLConnect and SQLCompare, I'd be willing to give that a try. Just let me know how if you think that's an appropriate approach. / comments
Thanks for the reply. The only reason that this issue came up is because my SQL SourceControl and SQLConnect are using the same SVN repository and the same database, but SQLConnect says the File Ta...
OK. That was so easy that I'm almost embarrassed to have posted the question, but since it was the first time I'd tried SQL Source Control, I figured it was worth admitting my ignorance so as not to mess up the SQLConnect project.
I (almost) successfully linked the database to the SVN repository. There was an odd error that occurred in the process. The error message said something like "source control has changed something that it shouldn't have". I submitted the error message to Red-Gate and it hasn't come back.
I do have a problem with a FileTable comparing differently in SQLConnect, SQLCompare and SQL Source Control, but that's unrelated to the original issue so I'll post it separately.
Thanks for responding to this question so quickly. / comments
OK. That was so easy that I'm almost embarrassed to have posted the question, but since it was the first time I'd tried SQL Source Control, I figured it was worth admitting my ignorance so as not t...