Comments
Sort by recent activity
In case it is of importance:
The developer is running 32-bit Windows Server against a SQL 2005 instance. I am running 64-bit Windows 7 against the same SQL 2005 instance. The database is in 90 compatibility mode. We both have the latest version of SQL Dependency Tracker (2.50.0.558). / comments
In case it is of importance:
The developer is running 32-bit Windows Server against a SQL 2005 instance. I am running 64-bit Windows 7 against the same SQL 2005 instance. The database is in 90 co...
To clarify the situation, I reproduced what one of the developers showed me to better understand it. When the database with a huge number of objects is selected, only the database container is listed immediately (sub-second). No objects within the database are listed for possible selection. All the other databases on the server (with significantly fewer objects) operate as expected and take varying amounts of time to present their selection list.
I am a sysadmin on the server and experience the same results as the developer (who had non-dbo specific rights granted for SQL Compare, Data Compare, etc.). / comments
To clarify the situation, I reproduced what one of the developers showed me to better understand it. When the database with a huge number of objects is selected, only the database container is lis...
We are experiencing the same symptom, but most likely a different cause. Permissions are fine since SQL Compare works perfectly with the database (scripting, comparing, and synchronizing), but SQL Dependency Tracker does not list out the objects. The database is a PeopleSoft database with a large number of customizations, so the object count is huge. In excess of 5000 tables, 2000 procedures, etc., which occasionally even makes SSMS Object Explorer choke.
Oddly, it immediately presents a sub-set of the objects (i.e. it doesn't wait 30 or 60 seconds first). On another very large database, but smaller, it takes about 20 seconds before it presents all the objects. If it were timing out, I would expect it reach 30 seconds (as an example) but it doesn't for this particularly large database. It presents the short list of objects in about 1-2 seconds with no error message being presented.
Any thoughts or suggestions?
Thanks,
David R Buckingham / comments
We are experiencing the same symptom, but most likely a different cause. Permissions are fine since SQL Compare works perfectly with the database (scripting, comparing, and synchronizing), but SQL...
When the DEFAULT constraint is created inline with the column definition (named or not), SQL Server considers it a column constraint. When it is created at the end of the table creation or via a subsequent ALTER TABLE command, SQL Server considers it a table constraint. It is marked accordingly as such (table or column constraint) in the system tables. This is most likely the source of the issue (as I've run into it in the past myself).
There would have to be logic added that compared the functionality and disregarded if it was functionally identical whether it was considered a column constraint or a table constraint. / comments
When the DEFAULT constraint is created inline with the column definition (named or not), SQL Server considers it a column constraint. When it is created at the end of the table creation or via a s...
I would suggest offering at least 2 different hierarchies, if not a customizable one. The traditional VS database project style and the newer VS DBPro style (which is far more complex). The traditional database project style would be ideal in my world, as most of the tools I use are already configured to work with it.
On the flip side, SQL Compare would need to be able to cycle through all the sub-directories for comparison purposes, which it does not do at the moment. / comments
I would suggest offering at least 2 different hierarchies, if not a customizable one. The traditional VS database project style and the newer VS DBPro style (which is far more complex). The tradi...
I wholeheartedly concur with rgribble's suggestion. / comments
I wholeheartedly concur with rgribble's suggestion.