Comments
Sort by recent activity
Having done a couple of experiments with check constraints, I'd quite like to know how you're managing to get the constraint name schema-qualified in the first place- could you give us an example of what you think that ALTER TABLE ADD CONSTRAINT statement should look like / the creation script that originally made this constraint?
I've tried:
Just putting the schema name and a dot before the constraint name (SQL Server tells me I have a syntax error at the dot)
Logging on as someone with a default schema other than dbo and giving no schema information (SQL Server doesn't schema-qualify the constraint name)
Putting one set of square brackets around it (everything just treats the . as another character, including SQL Compare)
Creating the table in the same batch as the CREATE SCHEMA statement (this only schema-qualifies the table, not the constraint)
And I've tried these methods with the constraint as an inline constraint, as a table constraint, and as a constraint introduced by ALTER TABLE ADD CONSTRAINT, with no better results.
----
Michelle Taylor - michelle.taylor@red-gate.com
SQL Compare Test Team / comments
Having done a couple of experiments with check constraints, I'd quite like to know how you're managing to get the constraint name schema-qualified in the first place- could you give us an example o...
When you say 'when I compare it with SQL Compare', do you mean 'when I compare that live database to anything with SQL Compare'?
If SQL Compare is reporting the live database as containing quotes, then it looks like your sys.syscomments table contains the stored procedure with quotes. Could you run the following query:
SELECT text FROM sys.syscomments WHERE id = OBJECT_ID('dbo.BillingReport')
and tell me if it has quote marks or not?
If that query doesn't show quote marks, an empty copy of your database would be great - SQL Compare only deals with the schema.
If that query does show quote marks, I'm afraid the problem is that your database has quote marks around the name in its internal representation of the object, which is what SQL Compare retrieves, and therefore SQL Compare is always going to report quote marks from that database, and they're going to keep showing up as a difference until we manage to get the fix in to ignore the kind of quotes around textual object names. / comments
When you say 'when I compare it with SQL Compare', do you mean 'when I compare that live database to anything with SQL Compare'?
If SQL Compare is reporting the live database as containing quotes, ...
I've never seen this behaviour before...
Are you sure that the original copy of the database (that you took the snapshot of) didn't have quotes around the object name instead of brackets? That's the only way I've managed to get quotes into a snapshot.
If it's actually converting the brackets into quotes, I would love a copy of your database snapshot and a backup of the database you've taken it from, if at all possible (you can send them to michelle.taylor@red-gate.com). Hopefully with those we can reproduce and fix the problem. If you created the snapshot from a project (rather than just the export data source window with the Other Data Source tab), it would also be good to know what options were set in that project.
Unfortunately there isn't currently a way to ignore the kind of bracketing in the procedure name - I've added your request to the bug open in our bug tracking system about the problem. Because Stored Procedures are a 'textual' object (i.e. SQL Server remembers the actual text of the CREATE statement) doing non-textual comparisons (e.g. ignoring the difference between quotes and brackets) is not entirely trivial, alas. / comments
I've never seen this behaviour before...
Are you sure that the original copy of the database (that you took the snapshot of) didn't have quotes around the object name instead of brackets? That's th...
If you're thinking of upgrading to Toolkit 6, bear in mind that version 6 is .NET 2.0 only - 5 is the last toolkit that supports .NET 1.1. / comments
If you're thinking of upgrading to Toolkit 6, bear in mind that version 6 is .NET 2.0 only - 5 is the last toolkit that supports .NET 1.1.
Object-level mapping is on our list of possible future features (and I've updated the list item with your request), but there are currently no plans to implement it in the short term, as there are several other more regularly requested features that we want to implement first. / comments
Object-level mapping is on our list of possible future features (and I've updated the list item with your request), but there are currently no plans to implement it in the short term, as there are ...
We've completely changed the way that we handle included columns in indexes in 6.0 (the previous way was causing some problems with xml columns). I don't know if your particular problem has been solved because I can't reproduce it, but I encourage you to download a free trial of 6.1 and see if it's fixed.
(If the problem isn't fixed, please comment again to tell us and we'll make sure it's in our list of things to fix.) / comments
We've completely changed the way that we handle included columns in indexes in 6.0 (the previous way was causing some problems with xml columns). I don't know if your particular problem has been so...
Unfortunately the patch does not help in the case where you have a user with a default schema set up, and they create certain kinds of object in your database (triggers, views, functions, stored procedures). The problem here is that SQL Server stores internally the exact text that the user submitted for these objects, and when a user has a non-dbo default schema, that text does not include the information about what schema the object is in.
SQL Compare uses this internal text directly (which lets us preserve details such as whether the name was bracketed), which doesn't work if the user who is doing the synchronization has a different default schema from the user who entered the object into the database.
I've raised a bug in our bug tracking system about the default schema issue, but I'm afraid it's unlikely to be fixed for some time, as we've finalised what's going into 6.1.
Meanwhile, the workaround is to always fully qualify names that you use in triggers, views, functions and stored procedures, and to manually qualify names in old objects of these types as you find them, as you have been doing. / comments
Unfortunately the patch does not help in the case where you have a user with a default schema set up, and they create certain kinds of object in your database (triggers, views, functions, stored pr...
Thanks a lot for the email.
It looks like the problem is that our case sensitivity auto-detection doesn't work when you have a binary-collation database.
Meanwhile you can work around the problem like this:
1) Make a new project with your live database and some other database, with the case sensitivity option turned on
2) Compare Now
3) Go to the File menu and select Export a Data Source...
4) Make the snapshot from the tab with the already-registered live database on it.
Sorry about that; we'll have a proper fix in the next release, but I can't say when that will be, as we've only just released 6.1! / comments
Thanks a lot for the email.
It looks like the problem is that our case sensitivity auto-detection doesn't work when you have a binary-collation database.
Meanwhile you can work around the problem l...
That's strange - I have a database with duplicate-named users here, and I can save it to a snapshot with no problem (SQL Compare automatically detects that it should use case sensitivity).
If you could send us (michelle.taylor@red-gate.com) the server collation and database collation, and (if you can) a database backup of the affected database, we'll have a look into it - this does sound like there is a bug with our auto-detection of case sensitive databases. / comments
That's strange - I have a database with duplicate-named users here, and I can save it to a snapshot with no problem (SQL Compare automatically detects that it should use case sensitivity).
If you c...
I've tried a few basic tests with databases containing objects differing only by case, and have succesfully made snapshots of those. So it looks like it's something more complicated than just case sensitivity (or a failure in our case-sensitivity detection) that's causing you this problem.
Do your snapshots fail to save out to disk at all, or are you having trouble comparing them to other databases after successfully saving them?
If they're not saving out, or you've checked your options are correct for comparing them to other databases but they're still not working, we'll need some more information to look into this properly:
Ideally, we'd like one of the failing snapshots (if they're getting written out at all), and/or a database backup of the live databases they're coming from, but I understand not everyone can give out this kind of thing.
We'd also like to know what your server collation is (for each affected server), what the database collation of the database with failing snapshots is, and what the database collation of the databases you're comparing against is (if you are getting to the comparison stage).
Hopefully with this information we can reproduce your problem and find a solution. / comments
I've tried a few basic tests with databases containing objects differing only by case, and have succesfully made snapshots of those. So it looks like it's something more complicated than just case ...