Comments
Sort by recent activity
No problem, glad it's sorted :-)
Rob / comments
No problem, glad it's sorted :-)
Rob
Hi,
The version of 611 suggests it's a SQL 2005 (Pre-SP2) backup that you're trying to restore to a SQL 2000 server.
There's some details on database version vs. server version and compatibility level here: http://www.sqlskills.com/blogs/paul/200 ... Level.aspx
Hope that helps,
Robert / comments
Hi,
The version of 611 suggests it's a SQL 2005 (Pre-SP2) backup that you're trying to restore to a SQL 2000 server.
There's some details on database version vs. server version and compatibility le...
Hi,
You might like to have a look at SQL Compare and SQL Data Compare, if you're trying to pull individual objects out of a backup.
SQL Data Compare 6 and later ("Pro" edition) can ready data directly from a backup file, and synchronise it into a live database, so if you've already got a way of recreating an empty table into which you can pull the data, that should do the trick. You can also chose the data to import on a row-by-row basis, or compare a backup to a live database, if you're just looking at the changes made over a period of time.
In SQL Compare 7 Pro, which should be coming out fairly soon now, you'll also be able to do the same for the schema, so even if you don't have the schema available, you can pull that out from the backup.
Hope that helps,
Robert / comments
Hi,
You might like to have a look at SQL Compare and SQL Data Compare, if you're trying to pull individual objects out of a backup.
SQL Data Compare 6 and later ("Pro" edition) can ready data direc...
Hi,
Because we don't install anything on the SQL Servers, all the data passes through the machine running SQL Data Compare. Note that if you're using the GUI, all the data is fetched in the comparison stage, and only pushed back to the target during the synchronization (i.e. we don't read the data twice).
Hope that helps,
Robert / comments
Hi,
Because we don't install anything on the SQL Servers, all the data passes through the machine running SQL Data Compare. Note that if you're using the GUI, all the data is fetched in the compari...
Hi,
It's a parallel install in the sense that you can continue to use v5 with v6 installed, but obviously we can't ensure full backwards compatability in the sense of running v6 projects in v5 since v6 has introduced new features.
However, I agree that just opening a project in the later version shouldn't cause it to break. I think, if memory serves me correctly, that there was a bug in v5 in our date handling code. This was fixed for v6, but looks like it had the side effect of saving dates to disk in a format no longer readable by v5. In this case, it's due to the "last compared" date, which is set on the project whenever you run a comparison in the UI.
If you need to run v5 projects in the v5 UI (and also be able to run them on the v5 command line), I'd suggest making the project files read-only on disk - this should prevent the last compared date from being written back.
Regards,
Robert / comments
Hi,
It's a parallel install in the sense that you can continue to use v5 with v6 installed, but obviously we can't ensure full backwards compatability in the sense of running v6 projects in v5 sinc...
Hi,
Most implementations of SQL (including SQL Server) work on the basis that the order of fields isn't important, which is why you just see the fields added at the end. This also means that SQL Compare doesn't show up any difference between the tables. I don't think there's any way of inserting a field in a certain place in a table except by dropping and recreating the entire table.
Performance wise, there shouldn't be a difference, or at least none of any significance.
If you're using SELECT * statements, then you'll see the different ordering like you suggest, but as long as you index into them from your code using field names rather than numbers, you should be fine. So don't rely on a field being 3rd from the start, for example, as that might change. If you're working in ADO.NET, then you can index into an IDataRecord using a string, or you can call GetOrdinal() to get the number of the column with a given name. Both of these should be safe.
Hope that helps,
Robert / comments
Hi,
Most implementations of SQL (including SQL Server) work on the basis that the order of fields isn't important, which is why you just see the fields added at the end. This also means that SQL Co...
Hi,
If your original database has had larger amounts of data in it in the past, which has since been deleted, it may have a relatively large amount of unused space in the file on disk.
SQL Server doesn't automatically shrink data files, since repeated shrinking and growing can lead to fragmentation.
Have a look at http://msdn.microsoft.com/en-us/library/ms188776.aspx - that might give you an indication of whether this is the case here.
Hope that helps,
Robert / comments
Hi,
If your original database has had larger amounts of data in it in the past, which has since been deleted, it may have a relatively large amount of unused space in the file on disk.
SQL Server d...
I think you're missing a space between the first and second includes:
/include:table:\[TAB1\]/include:table:\[TAB1\]
Rob / comments
I think you're missing a space between the first and second includes:
/include:table:\[TAB1\]/include:table:\[TAB1\]
Rob
Hi,
Are you using some /include or /exclude switches on your command line? It looks like you've got the syntax of one of those slightly wrong, specifically having too many bits of text separated by semicolons.
If you could post the way you're invoking the command line, I'll see if I can spot where you're going wrong.
Cheers,
Robert / comments
Hi,
Are you using some /include or /exclude switches on your command line? It looks like you've got the syntax of one of those slightly wrong, specifically having too many bits of text separated by...
Hi Paul,
Thanks for the suggestion - we have considered doing something along these lines, but we're obviously somewhat wary about needing to make schema changes on people's databases :-).
However, I can see something like this could be useful in the situation where the servers are linked by a (relatively) slow network. We'll certainly continue to consider it in the future.
Thanks,
Robert / comments
Hi Paul,
Thanks for the suggestion - we have considered doing something along these lines, but we're obviously somewhat wary about needing to make schema changes on people's databases :-).
However,...