Comments
Sort by recent activity
Hi,
Also, it is possible that some will want to use one extended property for Descriptions and one for casual Notes
Yes I think this is a good idea as you might want to note different information without changing the DB documentation.
Also thinking about the link back to SQL Doc in the other direction, things like Notes entered in the other Red-Gate products would be a good optional extra to include in the documentation.
But I think I've already raised something along those lines with you in the SQL Doc forum. :-)
Cheers,
Alex / comments
Hi,
Also, it is possible that some will want to use one extended property for Descriptions and one for casual Notes
Yes I think this is a good idea as you might want to note different informati...
I agree, consistency with SQL Compare in this regard is important.
Janez's idea makes sense to me as well.
Thanks / comments
I agree, consistency with SQL Compare in this regard is important.
Janez's idea makes sense to me as well.
Thanks
Hi,
I'd like to second this feature.
I think that it's important that all Red-Gate's products should refer to Schema and Object Name in the object lists.
I also think the schema should be referred to as Schema as well (not Owner as SQL Compare does). I do understand the problem of backwards compatibility with SQL Server 2000 as it doesn't have schemas explicitly, but I think that as Owner effectively stood for Schema in 2000 and no longer does in 2005> then the change of description is valid.
Please see my request in the SQL Data Compare 8 (Early Access Program) forum http://www.red-gate.com/MessageBoard/viewtopic.php?t=8935 for more information.
Thanks
Alex / comments
Hi,
I'd like to second this feature.
I think that it's important that all Red-Gate's products should refer to Schema and Object Name in the object lists.
I also think the schema should be referred ...
Hi David,
They're in separate files. We have a folder called Static Data that we use to store the files with inserts.
An alternative would to be exclusive about the folders used on the compare. So that only folders defined in the SQL Compare options area are actually used (optionally) rather than parse every .sql file under the top level folder - just a thought.
Alex Weatherall / comments
Hi David,
They're in separate files. We have a folder called Static Data that we use to store the files with inserts.
An alternative would to be exclusive about the folders used on the compare. So ...
I've just noticed this as well. / comments
I've just noticed this as well.
Simon,
You were quite right - that was "just the thing" I was looking for [image]
Nice one Redgate! I'll get back to you with feedback when I can.
Regards,
Alex / comments
Simon,
You were quite right - that was "just the thing" I was looking for
Nice one Redgate! I'll get back to you with feedback when I can.
Regards,
Alex
I've just turned on verbose logging (as described in another recent post) and I see the event where a file with a syntax error is processed, however it just says Processing file: test_bad_syntax.sql [image]
:idea: Feature Request: Can a warning be written to this log if SQL Compare isn't able to process any file in a scripts folder?
Thanks,
Alex / comments
I've just turned on verbose logging (as described in another recent post) and I see the event where a file with a syntax error is processed, however it just says Processing file: test_bad_syntax.sq...
Thanks Simon,
I have the 8 beta so I will see how that works in comparison. I should have checked that first before posting - sorry.
Alex / comments
Thanks Simon,
I have the 8 beta so I will see how that works in comparison. I should have checked that first before posting - sorry.
Alex
The only thing I would say about including row count value on the tables page is that this information should be optional on the tables list (and the table page for that matter ) - like the SQL Script option.
The reason for this is that some users of SQL Doc are using your product to document databases that have many production instances (e.g. a database that's part of a product rather than in-house database). In these situations rowcount is not relevant (and the documentation is usually generated on non-production databases anyway - so the rowcount is of test or dev data.)
Totally agree about not using count_big(*) for the rowcount. Then again I don't run SQL Doc against a production database.
Thanks,
Alex / comments
The only thing I would say about including row count value on the tables page is that this information should be optional on the tables list (and the table page for that matter ) - like the SQL S...
Hi David,
I don't mind if different extended properties are stored in the database so long as it's seamless in the GUI. i.e. I wouldn't want to manually maintain both copies - I'd expect to edit my description in HTML mode and it maintain a plain text version in MS_Description and the HTML version in HTML_Description.
This brings me to another question that may have been asked before. Are you planning on supporting editing bespoke extended properties?
Thanks,
Alex / comments
Hi David,
I don't mind if different extended properties are stored in the database so long as it's seamless in the GUI. i.e. I wouldn't want to manually maintain both copies - I'd expect to edit m...