Showing posts with label isthere. Show all posts
Showing posts with label isthere. Show all posts

Wednesday, March 21, 2012

Diff for tables *structures* rather than data

If I have two sql server databases that started out with identical
table/key/index structures, but were not properly kept in sync, is
there any way I can generate a table change script to essentially
'diff' the two databases and come up with table change scripts to
bring one in line with the other?

An answer to this age-old question of mine would make me very
happy...!

BrianERwin will do this easily for you (reverse engineer one database and then do
a compare with the other). PowerDesigner and ER/Studio will probably also
do it.

Downside? They're not free...

To find out what's different, you could do something like this:

select so.name, sc.name, sc.type from sysobject so inner join syscolumns sc
on so.id = sc.id
order by so.name, sc.name

in both databases, paste the output into .TXT files and then do a compare on
the .TXT files (WINDIFF utility) to get started. You'll have to generate
the change scripts by hand, of course.

You could completely script the databases and then WINDIFF the scripts.
However, the scripting order might be different between the two databases
and this may muddy the waters (you could rearrange the scripts by hand to
resolve some ordering problems).

If you have a little money, see if you can find a database consultant with
access to ERwin or one of the other tools to come in for a couple of hours
and use his tools to generate the scripts for you. It might save a lot of
time. You could ask him to print diagrams, too, which might be helpful down
the road.

If you have a fair amount of cash, consider buying one of these tools
yourself - they're very, very handy. ER/Studio used to offer a freely
downloadable demo; don't know about ERwin or PowerDesigner. It seems to me
that ERwin is something like $4000. I think ER/Studion was less, don't
recall about PowerDesigner.

DesktopDBA, if it's still around, may also offer some capability this way.

I suppose you could check C|Net, SQLServerCentral or some of the other
SQL-oriented group sites for freely downloadable utilities, too.

"Brian McGee" <brian.mcgee@.Sentrio.com> wrote in message
news:831a513c.0309110332.2184b751@.posting.google.c om...
> If I have two sql server databases that started out with identical
> table/key/index structures, but were not properly kept in sync, is
> there any way I can generate a table change script to essentially
> 'diff' the two databases and come up with table change scripts to
> bring one in line with the other?
> An answer to this age-old question of mine would make me very
> happy...!
> Brian|||In article <831a513c.0309110332.2184b751@.posting.google.com>,
brian.mcgee@.Sentrio.com says...
> If I have two sql server databases that started out with identical
> table/key/index structures, but were not properly kept in sync, is
> there any way I can generate a table change script to essentially
> 'diff' the two databases and come up with table change scripts to
> bring one in line with the other?

I like Red-gate Softwares "SQL Tools" product for that.
(http://www.red-gate.com) You can get a single-user license for the SQL
Compare portion of the product for about $200. That would bring the
table definitions in line. If you also want scripts to modify the
contents of the tables, that's another $200. Of course, at that point
you're better off with the bundle, which is $350 and includes DTS
Compare which diffs server settings, DTS packages, jobs and logins.

-- Rick

P.S. No affiliation at all with Red-Gate software but their product
saved my cojones once, so I'm just passing on my experience.

Tuesday, February 14, 2012

Determining numbers of rows affected in advance

Hi,
When workinf on a SQL2005 Db through Sql Server Management studio, is
there a way to determine in advance how many rows will be affected as
a result of an Update,Insert,or Delete statement without actually
performing the query?
thanks "in advance"
> When workinf on a SQL2005 Db through Sql Server Management studio, is
> there a way to determine in advance how many rows will be affected as
> a result of an Update,Insert,or Delete statement without actually
> performing the query?
No, but you can execute the DML in a transaction, select @.@.ROWCOUNT and then
rollback. Another method is to determine the number of rows that will be
affected is to change the DML to a SELECT COUNT(*) query.
Hope this helps.
Dan Guzman
SQL Server MVP
"Aamir Ghanchi" <aamirghanchi@.gmail.com> wrote in message
news:6b8c041a-2093-43c4-b294-3f4b908f36c3@.r60g2000hsc.googlegroups.com...
> Hi,
> When workinf on a SQL2005 Db through Sql Server Management studio, is
> there a way to determine in advance how many rows will be affected as
> a result of an Update,Insert,or Delete statement without actually
> performing the query?
> thanks "in advance"
|||Aamir
I'm not sure what you mean by 'through SQL Server Management Studio' but I
strongly recommend you don't do any data modification through a graphical
window, but always do it through TSQL code, using a query window or
application. You have much more control, and the ability to use the
techniques Dan suggested.
If you only want an estimate, you could also just look at the estimated
query plan after entering your query in a query window. You can get this
plan with Cntl-L
If you hold your cursor over the estimated plan's first icon, it should
display the estimated number of rows to be returned.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Aamir Ghanchi" <aamirghanchi@.gmail.com> wrote in message
news:6b8c041a-2093-43c4-b294-3f4b908f36c3@.r60g2000hsc.googlegroups.com...
> Hi,
> When workinf on a SQL2005 Db through Sql Server Management studio, is
> there a way to determine in advance how many rows will be affected as
> a result of an Update,Insert,or Delete statement without actually
> performing the query?
> thanks "in advance"
|||The SELECT COUNT(*) method can be much more efficient than your actual DML
statement because it will probably (hopefully!!) have a very tight, cheap
query plan using indexes since it just needs a count. And if you then DO
choose to run the actual statement then these pages will already have been
pulled into RAM hopefully making the run of the DML faster. Note that this
is still only recommended if for some reason you really do need the count
prior to the execution.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:34560279-FE9B-4EA1-BBBF-36ABFCB77F22@.microsoft.com...
> No, but you can execute the DML in a transaction, select @.@.ROWCOUNT and
> then rollback. Another method is to determine the number of rows that
> will be affected is to change the DML to a SELECT COUNT(*) query.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Aamir Ghanchi" <aamirghanchi@.gmail.com> wrote in message
> news:6b8c041a-2093-43c4-b294-3f4b908f36c3@.r60g2000hsc.googlegroups.com...
>
|||But for anything but really trivial quries, that optimizer estimate is
probably so off that it may not be very useful.
Linchi
"Kalen Delaney" wrote:

> Aamir
> I'm not sure what you mean by 'through SQL Server Management Studio' but I
> strongly recommend you don't do any data modification through a graphical
> window, but always do it through TSQL code, using a query window or
> application. You have much more control, and the ability to use the
> techniques Dan suggested.
> If you only want an estimate, you could also just look at the estimated
> query plan after entering your query in a query window. You can get this
> plan with Cntl-L
> If you hold your cursor over the estimated plan's first icon, it should
> display the estimated number of rows to be returned.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://blog.kalendelaney.com
>
> "Aamir Ghanchi" <aamirghanchi@.gmail.com> wrote in message
> news:6b8c041a-2093-43c4-b294-3f4b908f36c3@.r60g2000hsc.googlegroups.com...
>
>
|||Well, I did say it was only an estimate. :-)
It may be way off, but it might not be. I think it would be better than
nothing, and perhaps better than completely running the whole query just to
get a rowcount, depending on how exact the OP needs the number to be.
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://blog.kalendelaney.com
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:237D20BB-D329-464B-974E-D74B48C80E6B@.microsoft.com...[vbcol=seagreen]
> But for anything but really trivial quries, that optimizer estimate is
> probably so off that it may not be very useful.
> Linchi
> "Kalen Delaney" wrote:
|||Thanks for all the responses.
And I'm sorry, should have clarified it. I am actually running a query
from query window in the management studio.
The estimate query plan was really way off and was in decimals ?
I liked the Rollback Transaction solution and it fits my needs. I know
it may be costly but I am not worried about that in my circumstances.
The Select and Selct Count statements are good but still not the same
as running the actual queries (some of them much complex with multiple
joins & subqueries)
Once again, thanks all.
On Jan 7, 12:21Xam, "Kalen Delaney" <replies@.public_newsgroups.com>
wrote:
> Well, I did say it was only an estimate. :-)
> It may be way off, but it might not be. I think it would be better than
> nothing, and perhaps better than completely running the whole query just to
> get a rowcount, depending on how exact the OP needs the number to be.
> --
> HTH
> Kalen Delaney, SQL Server MVPwww.InsideSQLServer.comhttp://blog.kalendelaney.com
> "Linchi Shea" <LinchiS...@.discussions.microsoft.com> wrote in message
> news:237D20BB-D329-464B-974E-D74B48C80E6B@.microsoft.com...
>
>
>
>
>
>
>
> - Show quoted text -