Comments
Sort by recent activity
Reading more I've found that I'm trying to work with an unsupported version of VS, Visual Studio Team Edition for Database Professionals.
Sorry. RTFM! / comments
Reading more I've found that I'm trying to work with an unsupported version of VS, Visual Studio Team Edition for Database Professionals.
Sorry. RTFM!
Yes, I seem to have put myself in a hole. I didn't mean check out when I was referring to the continuous integration builds. It is a get by label. The command line capabilities of SQL Compare 6 would then come into play for the build from the scripts. Sorry for creating problems over syntax. / comments
Yes, I seem to have put myself in a hole. I didn't mean check out when I was referring to the continuous integration builds. It is a get by label. The command line capabilities of SQL Compare 6 wou...
The problem has always been getting the scripts to run in the correct order to build the database. We've been working with manifests that determine script order and that in-house tool I mentioned earlier uses this to figure out the order for scripts. However, it's a pain the butt and a manual process, therefor prone to error. If we used SQL Compare for this it would be because SQL Compare can, quite successfully, figure out the correct script order on it's own automatically. / comments
The problem has always been getting the scripts to run in the correct order to build the database. We've been working with manifests that determine script order and that in-house tool I mentioned e...
We call the TFS command line now. / comments
We call the TFS command line now.
Shouldn't be an issue. We deploy from a label, not from the latest code. That way we always go from a known state. / comments
Shouldn't be an issue. We deploy from a label, not from the latest code. That way we always go from a known state.
Sure.
We have a continuous integration environment that we automatically build daily based on a label. We have to check the code out of the system and then run the build on a database. We've been doing this with an in-house system. We're looking at doing it with MS DBPro. DBPro actually won't manage the code at all so we have to use the TFS command line. If your tool worked that way, it wouldn't be an issue as long as we can then call all the compare & build functions from the command line. / comments
Sure.
We have a continuous integration environment that we automatically build daily based on a label. We have to check the code out of the system and then run the build on a database. We've been d...
David Atkinson wrote:
The other requests are as follows, roughtly in priority order:
- auto add new object files to source control
- auto delete object files from source control
- provide a list of source control modifications that SQL Compare intends to make
- option to get latest version of a scripts folder from within SQL Compare
- option to get labeled version of a scripts folder from within SQL Compare
And then make it do all this from the command line. See, we're reasonable people. / comments
David Atkinson wrote:
The other requests are as follows, roughtly in priority order:
- auto add new object files to source control
- auto delete object files from source control
- provide a list...
I had sent out several ideas in an email on this topic earlier, but I thought of one more. I don't think the tool should automatically check-in the changes it has made, but when you go to check them in, it would be good to get a summary of changes, and by this I simply mean a list of the items that are going to get updated, removed, inserted into source control so that I know the changes I'm expecting are there with no surprises. / comments
I had sent out several ideas in an email on this topic earlier, but I thought of one more. I don't think the tool should automatically check-in the changes it has made, but when you go to check the...
Good to know I'm not (too) crazy. / comments
Good to know I'm not (too) crazy.
David Atkinson wrote:
Can I ask why it is important to have different extensions for each object type? I would have thought that having .sql is the best as it is associated with your SQL editor by default.
David Atkinson
Red Gate Software
We used to do that, letting the extension define the object type so that a .prc is a procedure, .tbl is a table, etc. Just an attempt to let the file help you with documentation. I like how MS did it in DBPro much better. Everything is .sql, but it's .fkey.sql or whatever. That way you get the documentation within the name, but you get the nice clean extension for use with all the SQL tools. / comments
David Atkinson wrote:
Can I ask why it is important to have different extensions for each object type? I would have thought that having .sql is the best as it is associated with your SQL editor ...