Comments
13 comments
-
Adding to these comments, it would be great if there could be options for how to name the scripts, and whether to create a subdirectory heirarchy underneath the given folder.
Currently all scripts are created as [dbo].[object].sql
I would prefer to name them without the brackets, and im sure others again would prefer not to have the dbo at all.
I also dislike using .sql as the extension for everything... we use different extensions for different object types, such as .TAB for table, .PRC for stored proc, .UDF for function and so on (these file extensions come originally from enterprise manager, but we have extended/expanded this and defined our own extensions for 2005 objects too, such as ASM for assembly, SYN for synonym, XSC for XmlSchemaCollection etc).
We also like to store our objects in subfolders
root folder
/Functions
/StoredProcedures
/Tables
/Views
and so on.
I think ultimately you could provide users with a fair amount of flexibility by giving us a settings page allowing us to specify a file extension, and subfolder for each object type. This would allow users like Andrew to put all 200 objects in the root folder, and 2005 objects in a single subfolder, and having all files with a .sql extension, while allowing those like myself to configure a separate directory and file extension for each object type!
There should also be a global option for the filename part of the scripts - should they contain the owner/schema, should they have square brackets, maybe they should all be prefixed with the database name and an underscore. This could be implemented in a similar way to the arguments field in the application options, when specifying a custom program to view SQL scripts, by using placeholders like %SO% for schema/owner, %ON% for object name, %DN% for database name etc
[%SO%].[%ON%] = [dbo].[ObjectName]
%DN%_%SO%.%ON% = Database_dbo.ObjectName
etc... very flexible!
Supporting these kind of options will make this new feature infinitely more usable to a larger amount of your users -
I agree with rgribble's requests. We use the extensions produced by the old Enterprise Manager too.
-
rgribble wrote:Adding to these comments, it would be great if there could be options for how to name the scripts, and whether to create a subdirectory heirarchy underneath the given folder.
Currently all scripts are created as [dbo].[object].sql
I would prefer to name them without the brackets, and im sure others again would prefer not to have the dbo at all.
I also dislike using .sql as the extension for everything... we use different extensions for different object types, such as .TAB for table, .PRC for stored proc, .UDF for function and so on (these file extensions come originally from enterprise manager, but we have extended/expanded this and defined our own extensions for 2005 objects too, such as ASM for assembly, SYN for synonym, XSC for XmlSchemaCollection etc).
We also like to store our objects in subfolders
root folder
/Functions
/StoredProcedures
/Tables
/Views
and so on.
I think ultimately you could provide users with a fair amount of flexibility by giving us a settings page allowing us to specify a file extension, and subfolder for each object type. This would allow users like Andrew to put all 200 objects in the root folder, and 2005 objects in a single subfolder, and having all files with a .sql extension, while allowing those like myself to configure a separate directory and file extension for each object type!
There should also be a global option for the filename part of the scripts - should they contain the owner/schema, should they have square brackets, maybe they should all be prefixed with the database name and an underscore. This could be implemented in a similar way to the arguments field in the application options, when specifying a custom program to view SQL scripts, by using placeholders like %SO% for schema/owner, %ON% for object name, %DN% for database name etc
[%SO%].[%ON%] = [dbo].[ObjectName]
%DN%_%SO%.%ON% = Database_dbo.ObjectName
etc... very flexible!
Supporting these kind of options will make this new feature infinitely more usable to a larger amount of your users
We are planning to make the script naming/location more flexible in the final release. You will be able to select the folder for indiuvidual object types, as well as a prefix for that particular object.
Regards,
Andras -
Just to pile on a bit to what the others said, we've been using Microsoft's Visual Studio Team Edition for Database Professionals for a while now. More and more of our scripts are in their formats. Despite having this tool from MS, your product(s) is still very much in use around here. If we are to use the script comparison, it would need to work more along the lines of what MS has done to us (note, to us, not necessarily for us).
-
Granted wrote:Just to pile on a bit to what the others said, we've been using Microsoft's Visual Studio Team Edition for Database Professionals for a while now. More and more of our scripts are in their formats. Despite having this tool from MS, your product(s) is still very much in use around here. If we are to use the script comparison, it would need to work more along the lines of what MS has done to us (note, to us, not necessarily for us).
In the final release we will be allowing hierarchical script locations, so we will read in the creation files from the full directory tree.
Regards,
Andras -
hopefully that includes file extensions other than .sql files as well?
-
Andras wrote:In the final release we will be allowing hierarchical script locations, so we will read in the creation files from the full directory tree.
Does this mean that we'll be able to have a deep folder structure of scripts?
e.g.,
StoredProcedures
---- Folder1
FolderA
script1.sql
script2.sql
script3.sql
---- Folder2 -
Yes, any number of levels of subfolders will be supported.
For v6.0 our naming convention will be owner.objectname.sql
Depending on the quantity of feedback we get after the initial release, we will consider the possibility of making the filenames more flexible.
Currently they can be renamed by the user after they are generated by SQL Compare, but the only limitation is that they have a .sql extension!
David Atkinson
Red Gate Software -
Are you saying if I use a script folder structure as a comparison data source, but my scripts are named as "objectname.sql" instead of "dbo.objectname.sql", then it won't work?
-
Not at all. SQL Compare doesn't care what the files are called, as long as they have the .sql suffix, so objectname.sql will be fine just as much as dbo.objectfile.sql, or mysqlfile.sql! Each sql file can contain one or more objects, it won't matter. It's entirely up to you. Here at Red Gate, we try our hardest to allow for maximum flexibility.
But SQL Compare will by default use a fixed naming convention if you use it to export a database to scripts, or if you synch new objects to a scripts folder. This is because we feel that we haven't had enough feedback as to what nomenclature is required by our users to implement something that will satisfy the majority. Once we have this data we will make the default naming more flexible.
However, nothing is stopping you renaming the files that SQL Compare will create by default.
Hope this makes it clearer,
David Atkinson
Red Gate Software -
How is the suggestion to support wildcarded naming convention not flexible enough for practically ANY conceivable way someone would want it setup?
Provide us some wildcards for server (%SN%), database (%DN%), owner (%OW%), object (%ON%) etc, and we could then format it how we want
If you didnt have time to implement this, that's one thing... but to say you arent sure how to satisfy the majority... id like to know how the suggestion is not flexible enough to cater for nearly anyone's needs!
Does this mean that although you will support reading in from a nested subfolder heirarchy, the scripts you enerate from scratch will be all dumped into a single folder? So not only do we have to rename them, but also have to then somehow sort them into their proper folders (which is hard/cumbersome when all you have is the object name, and a .sql extension - no easy way to tell one object type from another).
I know ill be continuing to use my existing method of scripting files out, and just be using redgate to hopefully "build" into an empty staging database. A shame really
-
Don't worry - the release version will map object types to user-specified subfolders. So you will be able to configure SQL Compare to map all tables to \Tables and all Schemas to \Security\Schemas, etc...
The one thing you won't be able to do in v6.0 is choose how the SQL Compare-generated script files are named by default. If you have pre-existing script files, that's fine. You can use these, as long as they have the .sql extension.
We will definitely look at adding flexibility to SQL Compare's default naming convention going forward. If we implemented all features we wanted to for the first version of v6, we wouldn't get a release out any time soon. Some features inevitably miss the cut. Our priority is to get the essentials out in the first instance and subsequently fine tune it.
I hope you understand that there are time constraint vs feature trade offs at play here. We have listened to user feedback and we will look at how we can best provide an effective solution.
Best regards,
David Atkinson
Red Gate Software -
Yeah i understand... its just we hope for so much when we do these beta programs
Infact (and ive said this before), it would be really really good if RedGate could expand its idea of a beta program and deliver us at least ohne fo0llow up beta to the original, so we at least get a 2nd crack at it before the final version. I know it takes overhead to create a beta etc, but i think it would be worth it, and good to give those of us who had raised issues which are now apparently "fixed in the final release" to get another shot at testing it out for you guys, before it's too late! Regular beta updates would be even better...
Im glad to hear that subfolders can be defined though, so that is a bonus. In terms of file naming, at least the default doesnt have square brackets in it anymore... apart from the file extensions, it actually matches what we are using here anyway (owner.object)
Add comment
Please sign in to leave a comment.
We're excited by the potential of the new Script Comparison facility, as we maintain all our SQL objects as scripts in the file system so they can be managed by source control.
However there are a couple of shortcomings that would prevent it being useful to us:
- As Granted mentioned here, it'd be great if the scripts were more granular.
- We have 2000+ object files which we've separated into subdirectories so they're easier to manage and more efficient. It would be great if SQL Compare handled this.
Thanks,
Andrew