BugS QL Server 2005 Beta 2

Dear Newsgroup Members !
I think, and that's my real thinking, i never saw a SQL-Server where has so
many Bugs inside.
Ok, it's a Beta, but that's no OK.
After 3 Days work and 4 Installations the SQL-Server run exactly. OK, that's
live.
But the great BUG after a lot other befor, is the BUG where you can delete
some Databases in the SQL Server Managment Studio with 1 Action and without
any Delete-Question. The Databases are in Nirwana.
I get my Version up and wish you a good time.
Thanks
GeraldGerald (Gerald@.discussions.microsoft.com) writes:
> I think, and that's my real thinking, i never saw a SQL-Server where
> has so many Bugs inside.
> Ok, it's a Beta, but that's no OK.
> After 3 Days work and 4 Installations the SQL-Server run exactly. OK,
> that's live. But the great BUG after a lot other befor, is the BUG where
> you can delete some Databases in the SQL Server Managment Studio with 1
> Action and without any Delete-Question. The Databases are in Nirwana.
> I get my Version up and wish you a good time.
Beware that beta 2 is over a year old now. You find the most recent drop
here: http://www.microsoft.com/sql/2005/productinfo/ctp.mspx.
As for deleting database, I tried this and I got a dialog about
dropping an object. If you just pressed Delete by mistake, you should
react.
Also, please use the SQL 2005 newsgroups for SQL 2005, as these groups
are monitored by the SQL Server Devs. Access information here:
http://go.microsoft.com/fwlink/?linkid=31765
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

Bug in SELECT IN SELECT?

Hello,

we had a performance issue with our application. The application executed a lot of SELECT IN SELECT-Statements.

Because SQL-Server was at 100% the whole time we started the profiler and had a look. A single one of these SELECT IN SELECT-Statements had a duration from 4 to 6 seconds. That looked strange, so we tried it without our application. Executing the SELECT IN SELECT-Statement directly: 4-6 seconds. Very strange about this is, that the second SELECT (the one after IN) returned only one or two items. So we splitted it: Executed the second SELECT first. Then executed the first statement with manually changed IN-clause. Both selects didn't need any noticable time. So, back in our application we did the same. The result was that the process that took about 70 minutes with the SELECT IN SELECT run through in under 3 minutes with result = SELECT; SELECT in result.

Pretty strange, hu?

Is this a known bug? Is this a bug at all?

the query plan might give some clues to the bad performance. also, you might consider converting your IN() query into an Inner join.

Bug in MS Management Studio for SQL-Server 2005 while creating a publication!

Hello,

I found a bug in Management Studio, which can be reproduced with following steps:

1. Create a new publication with the 'New Publication Wizard'
2. Select a database which contains at least 2 tables.
3. Select 'transactional publicatioon'
4. Select at least 2 tables as articles
5. Set article properties for all table articles
6. Change 'Statement Delivery' to 'Insert statement', 'Update statement' and 'Delete statement' and save the article properties.
7. If you now check the properties for a single article you find that the 'Statement Delivery' is set to 'Do not replicate...'. If you generate this publication and create a subscritpion you will see, that actual no replication take place.

It took me a while to find out why my replication doesn't work! :-((

Wolfgang Kunk

PS : Management Studio version is 9.00.1399.00

Unfortunately that part of the wizard is kind of broke, and it won't get fixed for SP2 either. A similar issue was raised in an earlier post as well - http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=984751&SiteID=1.

The workaround is to either use TSQL scripts to set everything up, or set everything up with UI and then immediately issue a sp_changearticle to set it.

As a side note, may I ask why you want to use "Insert/Update/Delete statement" instead of the default stored proc? This can have bad performance impact against a SQL subscriber.

|||Normally we use T-SQL scripts to set up replication. So it is not a real big problem.
I wanted to see if it is a known bug!

Can you please explain what the bad performance impact can be?
As far as I know the default stored procs execute nothing else then a simple insert, update or delete statement. So I cannot see a bad impact. The only thing is that the optimizer optimzes a stored proc once while it has to optimize insert, update ans delete-statements every time.

Wolfgang Kunk|||

When using stored procs, each proc is fired off as an individual RPC, and the proc itself generates a plan that can be reused over and over for optimal performance.

When using SQL, we fit as many commands as we can (I think up to 500) into a single parameterized sp_executesql and execute it all at once. Meaning one single sp_executesql call can have anywhere from one to 500 different ins/upd/del statements - this generates one single plan. The next sp_executesql call will most likely be different, and generate a totally different plan. So what happens is every call will most likely have to be compiled because you'll never get plan reuse. In an OLTP scenario where you're replicating thousands of commands a second, you'lll definitely see an impact in performance.

For proof, apply a mixed/random workload to the publisher and then trace the distribution agent calls at the subscriber using SQL and stored procs, you'll see what I mean.

SQL is used mostly with heterogeneous subscriber cases and the very rare case when customer has a purpose for SQL subscriber cases.

|||Thanks for the explanation.

At the moment we only use heterogenous subscriber, where we work with SQL. So I used SQL for my first MS-MS Replication as well. I will take your recommendation in account for my further tests!

Wolfgang Kunk

brief help on most popular functions of sql-server

Hello,
I need a good help (*.chm file is fine),
for sql-server functions & bit more...
Thanks :)Don't you already have Books Online? If not, get it here:
http://www.microsoft.com/sql/techin...00/default.mspx
David Portas
SQL Server MVP
--|||I need something totaly free.
Thanks :)
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1124281451.457156.163980@.g49g2000cwa.googlegroups.com...
> Don't you already have Books Online? If not, get it here:
> http://www.microsoft.com/sql/techin...00/default.mspx
> --
> David Portas
> SQL Server MVP
> --
>|||>I need something totaly free.
The BOL download as well as web access is free via the link David posted.
Hope this helps.
Dan Guzman
SQL Server MVP|||>I need something totaly free.
There are no price tags on the link that David provided. Did you actually
go to the link? Did you click on Download? Were you asked for a credit
card?|||About the price - sorry, my mistake.
Also,
I know this online help,
and it seems too massy.
I need just simple help, like old phasion help (*.chm is good enough).
Thanks :)|||The Books Online download IS in CHM format! You'll find the functions
in tsqlref.chm. Do you need someone to come over and help you install
it!
David Portas
SQL Server MVP
--|||> I need just simple help, like old phasion help (*.chm is good enough).
Sorry, no such thing that I know of, SQL Server is much too complex to be
documented by a single .chm file.
Download books online, install it on your machine, and familiarize yourself
with the search and index functionality. If there is only one set of
documentation you will have, this is the one you want. And you can ignore
all the "massy" stuff you don't need.|||> The Books Online download IS in CHM format!
Ah yes, I am stuck in SQL Server 2005 world, where everything is
<guid>.htm...

> Do you need someone to come over and help you install
> it!
LOL! I was going to suggest the same thing.|||> Ah yes, I am stuck in SQL Server 2005 world, where everything is
> <guid>.htm...
Still trying to get used to that myself. The format change was
inevitable I suppose but I still find the multiple pane layout quite
hard work.
David Portas
SQL Server MVP
--