Activity overview
Latest activity by ciaranarcher
Hi Andy
When you say SQL Compare doesn't support SQL Server 2000 'anymore', can you tell me since when/version?
The reason I ask is that your website still says it does support SQL Server 2000: http://www.red-gate.com/supportcenter/c ... ng_Started
Thanks,
Ciaran
andy.campbell.smith wrote:
Actually, SQL Compare doesn't support SQL 2000 any more either, although it still just about works. SQL Source Control has never supported SQL 2000, though, and it's because of the way we collect trace information, not because of the Compare engine - the way we collect trace information is fundamentally incompatible with SQL 2000, so it's unlikely it'll ever be supported with SQL Source Control. Sorry!
/ comments
Hi Andy
When you say SQL Compare doesn't support SQL Server 2000 'anymore', can you tell me since when/version?
The reason I ask is that your website still says it does support SQL Server 2000: htt...
We use 2008 R2 to develop on (in 2000 compat mode) and have been using this since SQL Source Control V1, but production DBs are still on 2000. I only started using the new Migrations stuff features recently.
I thought SQL Source Control uses uses SQL Compare Pro to generate the migration script, and doesn't that support SQL Server 2000?
andy.campbell.smith wrote:
I'm afraid SQL Source Control doesn't actually support SQL Server 2000 - if you can get it working that's great, but we don't guarantee anything, and I know some features won't be too happy with it. Sorry!
/ comments
We use 2008 R2 to develop on (in 2000 compat mode) and have been using this since SQL Source Control V1, but production DBs are still on 2000. I only started using the new Migrations stuff features...
Error migrating from SQL Source Control to SQL Server 2000
I created a migration, committed it and when trying to run it against a SQL Server 2000 database, I get the following error:The following error message was returned from the SQL Server:
[208&#...
Ditto for us. We were deploying from SQL Server 2008 R2 to SQL Server 2000. The .160 release fixed the issue. / comments
Ditto for us. We were deploying from SQL Server 2008 R2 to SQL Server 2000. The .160 release fixed the issue.
Hi David
Yes the "auto-get-latest-when-there-are-no-conflicts" would be perfect! When can you ship it? [image]
And yes, the developers are aware of that Get Latest tab, but sometimes there are cross-database dependencies that mean getting the latest for more than one database to resolve.
And there is also the wait time (more than a few minutes) for updates on large database - and we have a few of those, so we'd love to be able to schedule that update overnight so the devs can have a up-to-date- version of all databases in the morning.
And ideally if there were conflicts it would be marked against the relevant database in SSMS to it's clear they need to be resolved.
I like the 'red indicators' suggestion - that would be a good start. I guess there are many ways to solve this problem. Another option is an 'auto-update-if-no-conflicts' option in SQL Source Control so there is no need to do any updates at all (provided there are no conflicts!)
As background: we use SVN for our regular source control and we have a large code base. A typical svn update might take a few minutes. So we just have a scheduled task running on every dev machine that runs a batch job to do that overnight both for convenience and to ensure that the lazy devs always have the latest [image] If there is a conflict the console window remains opened with the conflict details.
I guess were looking for a similar sort of workflow with SQL Source Control.
It's obviously not something I can do now via SQL Compare command line so we'll wait for that option I guess.
Thanks, Ciaran / comments
Hi David
Yes the "auto-get-latest-when-there-are-no-conflicts" would be perfect! When can you ship it?
And yes, the developers are aware of that Get Latest tab, but sometimes there are cross-datab...
Hi David
Well the target database is the local development database for the user, so these columns might be uncommitted work in progress.
What I'm trying to achieve here is an automatic update of the local database for a user. We have over a dozen databases, and we need to (ideally) have them all take changes automatically rather than the user having to update them using SQL Source Control in SSMS one at a time as this is time consuming for large databases.
So I need the update to avoid overwriting local changes, add any new changes and if there are any conflicts to throw an error as that will require manual intervention.
I hope I have the right tool for the job - if there was a way to call SQL Source Control form the command line (rather than via SSMS) then that might be better - if we could force a sync when there are no conflicts.
I hope that makes sense [image]
Cheers,
Ciaran
David Atkinson wrote:
Can I ask why it is that you've got additional columns in the target databases that don't exist in source control?
/ comments
Hi David
Well the target database is the local development database for the user, so these columns might be uncommitted work in progress.
What I'm trying to achieve here is an automatic update of t...
Thanks for that - I'd be very interested to know if it can be changed, or if there is some other day to ensure automatic update of local databases from SVN.
The solution we have is not all the way there and of questionable benefit if the local developer still has to do a manual update SSC in SSMS to ensure his local copy is up to date despite this script running.
Thanks for your feedback!
Ciaran / comments
Thanks for that - I'd be very interested to know if it can be changed, or if there is some other day to ensure automatic update of local databases from SVN.
The solution we have is not all the way ...
Wait - I'm actually sort of halfway there now [image]
The options above will preserve any added columns on my local copy, and preserve any added objects (like tables) in my local copy.
But if someone adds a column to a table in the scripts folder via SVN that I have not changed, then it doesn't see that change unless I remove the /exclude:different flag.
But of course if I do that, then any columns I have added to my local database will be removed in the sync.
Is there any way around this?
Thanks in advance. / comments
Wait - I'm actually sort of halfway there now
The options above will preserve any added columns on my local copy, and preserve any added objects (like tables) in my local copy.
But if someone add...
That did it! Thanks for the tip. / comments
That did it! Thanks for the tip.
Any further thoughts on this, anyone?
Thanks,
Ciaran / comments
Any further thoughts on this, anyone?
Thanks,
Ciaran