Optimizing Data Warehouse Query Performance Through Bitmap Filtering...

Hi, as per the BOL, In the "Optimizing Data Warehouse Query Performance Through Bitmap Filtering"

the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai according to sql Server 2008.

Can you verify it please.

Hi Akash,

What statements in the topic led you to that conclusion? I wrote the topic, so I want to make sure I correct any such sentences that can be perceived incorrectly.

Thanks,

Gail

|||

Hi Akash,

technically, there is no reason for higher cost of scans. Could you please point Gail to the BOL topic so that we can make sure that it is accurate?

Thanks,

Torsten Grabs [MSFT]

Program Manager

SQL Server Query Processor

|||

Hi Gail,

As i've mentioned that in the BOL when you type "Bitmap Index", you let the user understand how optimized bitmap filtering is implemented. You also demonstrate an example for it comparing both the SQL Server 2005 along with Katmai and in that very example you did mention that the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai when compared to sql Server 2005. Just have a look at the figures.

Clustered index scan costs 3% for DimProduct & 12% for DimCustomer in case of SQL Server 2008 where as the same clustering index scan costs 2% and 11% respectively in SQL Server 2005.

Similarly Table Scan costs 14% in SQL Server 2008 and 13% in case of SQL Server 2005.

Should not there be a decrese in scanning cost in Katmai when compared to SQL Server 2005 ?

|||

Hi Akash,

Thanks very much for the pointer to the BOL entry you were referring to. There are two considerations two keep in mind when comparing the table scan cost information as you do:

- Costing functions may change between releases. Hence, when you compare query plan costs and operator costs across releases, you are on unstable ground as you make the assumption that the costing function has not been changed.

- The percentages are relative costs. The less expensive the remaining query plan, i.e., the plan on top of the table scan, gets the higher this percentage value will be - assuming that the cost of the scan is the same. If you look into the subtree cost information of the scan, you will see that the cost is the same for both plans. But, the remaining operators, in particular the hash joins on top, have become cheaper since there are fewer rows to process - which explain why you see the percentages increase.

A further note on why the absolute costs between the scan operators remain the same: even with bitmap filters, the table scan operation has to read all the rows from the disk or buffer pool initially. However, as soon as the row is read into the query processor, we can apply the bitmap filter. The main cost, however, is spent in disk or buffer pool reads - the bitmap filter processing itself is very cheap. Therefore, we do not model the bitmap filtering cost in plan generation. However, optimized bitmap filters do model the cardinality changes of the bitmap filter on top of the scan operation.

Hope this explains the showplan information in the BOL topic.

Best regards,

Torsten Grabs [MSFT]

Program Manager

Microsoft SQL Server Query Processor

|||Thanks Torsten. It was really a great help,appreciate your effort in letting me understand this

Optimizing Data Warehouse Query Performance Through Bitmap Filtering...

Hi, as per the BOL, In the "Optimizing Data Warehouse Query Performance Through Bitmap Filtering"

the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai according to sql Server 2008.

Can you verify it please.

Hi Akash,

What statements in the topic led you to that conclusion? I wrote the topic, so I want to make sure I correct any such sentences that can be perceived incorrectly.

Thanks,

Gail

|||

Hi Akash,

technically, there is no reason for higher cost of scans. Could you please point Gail to the BOL topic so that we can make sure that it is accurate?

Thanks,

Torsten Grabs [MSFT]

Program Manager

SQL Server Query Processor

|||

Hi Gail,

As i've mentioned that in the BOL when you type "Bitmap Index", you let the user understand how optimized bitmap filtering is implemented. You also demonstrate an example for it comparing both the SQL Server 2005 along with Katmai and in that very example you did mention that the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai when compared to sql Server 2005. Just have a look at the figures.

Clustered index scan costs 3% for DimProduct & 12% for DimCustomer in case of SQL Server 2008 where as the same clustering index scan costs 2% and 11% respectively in SQL Server 2005.

Similarly Table Scan costs 14% in SQL Server 2008 and 13% in case of SQL Server 2005.

Should not there be a decrese in scanning cost in Katmai when compared to SQL Server 2005 ?

|||

Hi Akash,

Thanks very much for the pointer to the BOL entry you were referring to. There are two considerations two keep in mind when comparing the table scan cost information as you do:

- Costing functions may change between releases. Hence, when you compare query plan costs and operator costs across releases, you are on unstable ground as you make the assumption that the costing function has not been changed.

- The percentages are relative costs. The less expensive the remaining query plan, i.e., the plan on top of the table scan, gets the higher this percentage value will be - assuming that the cost of the scan is the same. If you look into the subtree cost information of the scan, you will see that the cost is the same for both plans. But, the remaining operators, in particular the hash joins on top, have become cheaper since there are fewer rows to process - which explain why you see the percentages increase.

A further note on why the absolute costs between the scan operators remain the same: even with bitmap filters, the table scan operation has to read all the rows from the disk or buffer pool initially. However, as soon as the row is read into the query processor, we can apply the bitmap filter. The main cost, however, is spent in disk or buffer pool reads - the bitmap filter processing itself is very cheap. Therefore, we do not model the bitmap filtering cost in plan generation. However, optimized bitmap filters do model the cardinality changes of the bitmap filter on top of the scan operation.

Hope this explains the showplan information in the BOL topic.

Best regards,

Torsten Grabs [MSFT]

Program Manager

Microsoft SQL Server Query Processor

|||Thanks Torsten. It was really a great help,appreciate your effort in letting me understand this

Optimizing Data Warehouse Query Performance Through Bitmap Filtering...

Hi, as per the BOL, In the "Optimizing Data Warehouse Query Performance Through Bitmap Filtering"

the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai according to sql Server 2008.

Can you verify it please.

Hi Akash,

What statements in the topic led you to that conclusion? I wrote the topic, so I want to make sure I correct any such sentences that can be perceived incorrectly.

Thanks,

Gail

|||

Hi Akash,

technically, there is no reason for higher cost of scans. Could you please point Gail to the BOL topic so that we can make sure that it is accurate?

Thanks,

Torsten Grabs [MSFT]

Program Manager

SQL Server Query Processor

|||

Hi Gail,

As i've mentioned that in the BOL when you type "Bitmap Index", you let the user understand how optimized bitmap filtering is implemented. You also demonstrate an example for it comparing both the SQL Server 2005 along with Katmai and in that very example you did mention that the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai when compared to sql Server 2005. Just have a look at the figures.

Clustered index scan costs 3% for DimProduct & 12% for DimCustomer in case of SQL Server 2008 where as the same clustering index scan costs 2% and 11% respectively in SQL Server 2005.

Similarly Table Scan costs 14% in SQL Server 2008 and 13% in case of SQL Server 2005.

Should not there be a decrese in scanning cost in Katmai when compared to SQL Server 2005 ?

|||

Hi Akash,

Thanks very much for the pointer to the BOL entry you were referring to. There are two considerations two keep in mind when comparing the table scan cost information as you do:

- Costing functions may change between releases. Hence, when you compare query plan costs and operator costs across releases, you are on unstable ground as you make the assumption that the costing function has not been changed.

- The percentages are relative costs. The less expensive the remaining query plan, i.e., the plan on top of the table scan, gets the higher this percentage value will be - assuming that the cost of the scan is the same. If you look into the subtree cost information of the scan, you will see that the cost is the same for both plans. But, the remaining operators, in particular the hash joins on top, have become cheaper since there are fewer rows to process - which explain why you see the percentages increase.

A further note on why the absolute costs between the scan operators remain the same: even with bitmap filters, the table scan operation has to read all the rows from the disk or buffer pool initially. However, as soon as the row is read into the query processor, we can apply the bitmap filter. The main cost, however, is spent in disk or buffer pool reads - the bitmap filter processing itself is very cheap. Therefore, we do not model the bitmap filtering cost in plan generation. However, optimized bitmap filters do model the cardinality changes of the bitmap filter on top of the scan operation.

Hope this explains the showplan information in the BOL topic.

Best regards,

Torsten Grabs [MSFT]

Program Manager

Microsoft SQL Server Query Processor

|||

Thanks Torsten. It was really a great help,appreciate your effort in letting me understand this

Optimizing Data Warehouse Query Performance Through Bitmap Filtering...

Hi, as per the BOL, In the "Optimizing Data Warehouse Query Performance Through Bitmap Filtering"

the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai according to sql Server 2008.

Can you verify it please.

Hi Akash,

What statements in the topic led you to that conclusion? I wrote the topic, so I want to make sure I correct any such sentences that can be perceived incorrectly.

Thanks,

Gail

|||

Hi Akash,

technically, there is no reason for higher cost of scans. Could you please point Gail to the BOL topic so that we can make sure that it is accurate?

Thanks,

Torsten Grabs [MSFT]

Program Manager

SQL Server Query Processor

|||

Hi Gail,

As i've mentioned that in the BOL when you type "Bitmap Index", you let the user understand how optimized bitmap filtering is implemented. You also demonstrate an example for it comparing both the SQL Server 2005 along with Katmai and in that very example you did mention that the cost of Clustered Index Scan as well as Table Scan takes more time in Katmai when compared to sql Server 2005. Just have a look at the figures.

Clustered index scan costs 3% for DimProduct & 12% for DimCustomer in case of SQL Server 2008 where as the same clustering index scan costs 2% and 11% respectively in SQL Server 2005.

Similarly Table Scan costs 14% in SQL Server 2008 and 13% in case of SQL Server 2005.

Should not there be a decrese in scanning cost in Katmai when compared to SQL Server 2005 ?

|||

Hi Akash,

Thanks very much for the pointer to the BOL entry you were referring to. There are two considerations two keep in mind when comparing the table scan cost information as you do:

- Costing functions may change between releases. Hence, when you compare query plan costs and operator costs across releases, you are on unstable ground as you make the assumption that the costing function has not been changed.

- The percentages are relative costs. The less expensive the remaining query plan, i.e., the plan on top of the table scan, gets the higher this percentage value will be - assuming that the cost of the scan is the same. If you look into the subtree cost information of the scan, you will see that the cost is the same for both plans. But, the remaining operators, in particular the hash joins on top, have become cheaper since there are fewer rows to process - which explain why you see the percentages increase.

A further note on why the absolute costs between the scan operators remain the same: even with bitmap filters, the table scan operation has to read all the rows from the disk or buffer pool initially. However, as soon as the row is read into the query processor, we can apply the bitmap filter. The main cost, however, is spent in disk or buffer pool reads - the bitmap filter processing itself is very cheap. Therefore, we do not model the bitmap filtering cost in plan generation. However, optimized bitmap filters do model the cardinality changes of the bitmap filter on top of the scan operation.

Hope this explains the showplan information in the BOL topic.

Best regards,

Torsten Grabs [MSFT]

Program Manager

Microsoft SQL Server Query Processor

|||Thanks Torsten. It was really a great help,appreciate your effort in letting me understand this sql

Opportunity to provide feedback on performance improvements in SQL Server...

Please consider giving your feedback or suggestions on the top 5 OLTP and data warehouse performance improvments you would like to see in the next version of SQL Server. Use the links below to provide your comments.

http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_OLTP_PERF_IMP_NEXT_SQL.aspx

http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_DW_PERF_IMP_NEXT_SQL.aspx

Thanks

Any thought on
1. Reverse Key, Functional based and Bit map indexes?
2. UPSERT Statement (Update and insert)
3. Regular expressions in SQL Server
4. Row level trigger (due since first version)

Thanks
Bushan.|||there should something similar to XML documentation for stored procedure as in C# for T-SQL.
That will help document stored Procedures. Please correct me if there already is similar feature.|||

I would like to see SQL Server have something like the MINUS set-operator I have used in ORACLE. It provides a very easy way to see if anything is different between two tables. It is not necessary to specify the columns or any sort of JOIN condition -- merely

SELECT * FROM A MINUS SELECT * FROM B

This simple query returns all rows from A that do not match all values in some row of B. (I seem to recall that duplicate rows are not easily identified by a MINUS query.)

|||

hi Uma,

I've got the silliest idea of them all !

how about an ETL diagraming tools. Something like a flowchart

or the ERD which allows me to analyze the flow

of the etl when i have it printed. The diagram alone should be sufficient to explain the entire flow which minimize my needs to scrutine the properties of the transform.

i've got an initial idea of how it may look like hope you be interested.

thanks,

joey

Opportunity to provide feedback on performance improvements in SQL Server...

Please consider giving your feedback or suggestions on the top 5 OLTP and data warehouse performance improvments you would like to see in the next version of SQL Server. Use the links below to provide your comments.

http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_OLTP_PERF_IMP_NEXT_SQL.aspx

http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_DW_PERF_IMP_NEXT_SQL.aspx

Thanks

Any thought on
1. Reverse Key, Functional based and Bit map indexes?
2. UPSERT Statement (Update and insert)
3. Regular expressions in SQL Server
4. Row level trigger (due since first version)

Thanks
Bushan.|||there should something similar to XML documentation for stored procedure as in C# for T-SQL.
That will help document stored Procedures. Please correct me if there already is similar feature.|||

I would like to see SQL Server have something like the MINUS set-operator I have used in ORACLE. It provides a very easy way to see if anything is different between two tables. It is not necessary to specify the columns or any sort of JOIN condition -- merely

SELECT * FROM A MINUS SELECT * FROM B

This simple query returns all rows from A that do not match all values in some row of B. (I seem to recall that duplicate rows are not easily identified by a MINUS query.)

|||

hi Uma,

I've got the silliest idea of them all !

how about an ETL diagraming tools. Something like a flowchart

or the ERD which allows me to analyze the flow

of the etl when i have it printed. The diagram alone should be sufficient to explain the entire flow which minimize my needs to scrutine the properties of the transform.

i've got an initial idea of how it may look like hope you be interested.

thanks,

joey

Opportunity to provide feedback on performance improvements in SQL Server...

Please consider giving your feedback or suggestions on the top 5 OLTP and data warehouse performance improvments you would like to see in the next version of SQL Server. Use the links below to provide your comments.

http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_OLTP_PERF_IMP_NEXT_SQL.aspx

http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_DW_PERF_IMP_NEXT_SQL.aspx

Thanks

Any thought on
1. Reverse Key, Functional based and Bit map indexes?
2. UPSERT Statement (Update and insert)
3. Regular expressions in SQL Server
4. Row level trigger (due since first version)

Thanks
Bushan.|||there should something similar to XML documentation for stored procedure as in C# for T-SQL.
That will help document stored Procedures. Please correct me if there already is similar feature.|||

I would like to see SQL Server have something like the MINUS set-operator I have used in ORACLE. It provides a very easy way to see if anything is different between two tables. It is not necessary to specify the columns or any sort of JOIN condition -- merely

SELECT * FROM A MINUS SELECT * FROM B

This simple query returns all rows from A that do not match all values in some row of B. (I seem to recall that duplicate rows are not easily identified by a MINUS query.)

|||

hi Uma,

I've got the silliest idea of them all !

how about an ETL diagraming tools. Something like a flowchart

or the ERD which allows me to analyze the flow

of the etl when i have it printed. The diagram alone should be sufficient to explain the entire flow which minimize my needs to scrutine the properties of the transform.

i've got an initial idea of how it may look like hope you be interested.

thanks,

joey

Opportunity to provide feedback on performance improvements in SQL Server...

Please consider giving your feedback or suggestions on the top 5 OLTP and
data warehouse performance improvments you would like to see in the next
version of SQL Server. Please use the links below to provide your comments.
http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
Thanks
Umachandar Jayachandran
Microsoft SQL Server Performance Team
SQL Server Engine Team Tips Blog at
http://blogs.msdn.com/sqltips/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.
Dude, Microsoft doesn't listen to customers... don't kid yourself
Umachandar Jayachandran [MS] wrote:
> Please consider giving your feedback or suggestions on the top 5 OLTP and
> data warehouse performance improvments you would like to see in the next
> version of SQL Server. Please use the links below to provide your comments.
> http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
> http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
> Thanks
> Umachandar Jayachandran
> Microsoft SQL Server Performance Team
> SQL Server Engine Team Tips Blog at
> http://blogs.msdn.com/sqltips/default.aspx
> This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hello susiedba@.hotmail.com,
s> Dude, Microsoft doesn't listen to customers... don't kid yourself
Ha! I had a nickle for everytime they listened to me and the customers I
worked with, I wouldn't need to work. You've either got an axe to grind or
don't have a clue.
Thanks,
Kent Tegels
http://staff.develop.com/ktegels/
|||On Fri, 13 Oct 2006 02:03:09 +0000 (UTC), Kent Tegels
<ktegels@.develop.com> wrote:
in <b87ad74a0568c8bc58f4dcddd0@.news.microsoft.com>

>Hello susiedba@.hotmail.com,
>s> Dude, Microsoft doesn't listen to customers... don't kid yourself
>Ha! I had a nickle for everytime they listened to me and the customers I
>worked with, I wouldn't need to work. You've either got an axe to grind or
>don't have a clue.
>Thanks,
>Kent Tegels
>http://staff.develop.com/ktegels/
>
And you clearly don't have any code assets in VB6 :: no forward
migration path other than a complete rewrite. And SQL Server 2000 won't
be supported on Vista. It seems yours is a rather myopic view.
Stefan Berglund
|||Hello Stefan,
SB> And you clearly don't have any code assets in VB6 :: no forward
SB> migration path other than a complete rewrite.
Yep, I woke and smelled the coffee early. All 40+ of my VB4/VB5/VB6 applications
are now running faster and more reliably in .NET, most of them since late
2003. I'm sorry if *you* are stuck in the stone ages, but frankly, *you*
made that decision.
SB> And SQL Server 2000
SB> won't be supported on Vista. It seems yours is a rather myopic
SB> view.
Yawn. I hear very few of my customers or users even talking about adopting
Vista anytime soon -- there's nothing in it that's an immediate driver for
them. I am hearing chatter about IIS7, so *maybe* Longhorn looks to be painful
for them. Of course, they still have the option of running on Server 2003
R2 until they are migrated to SQL 2005.
So I'm not so sure that I'm the only one that's suffering from myopia, Stefan.

Thanks,
Kent Tegels
http://staff.develop.com/ktegels/

Opportunity to provide feedback on performance improvements in SQL Server...

Please consider giving your feedback or suggestions on the top 5 OLTP and
data warehouse performance improvments you would like to see in the next
version of SQL Server. Please use the links below to provide your comments.
http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
Thanks
Umachandar Jayachandran
Microsoft SQL Server Performance Team
SQL Server Engine Team Tips Blog at
http://blogs.msdn.com/sqltips/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.
Dude, Microsoft doesn't listen to customers... don't kid yourself
Umachandar Jayachandran [MS] wrote:
> Please consider giving your feedback or suggestions on the top 5 OLTP and
> data warehouse performance improvments you would like to see in the next
> version of SQL Server. Please use the links below to provide your comments.
> http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
> http://blogs.msdn.com/sqltips/archiv..._NEXT_SQL.aspx
> Thanks
> Umachandar Jayachandran
> Microsoft SQL Server Performance Team
> SQL Server Engine Team Tips Blog at
> http://blogs.msdn.com/sqltips/default.aspx
> This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hello susiedba@.hotmail.com,
s> Dude, Microsoft doesn't listen to customers... don't kid yourself
Ha! I had a nickle for everytime they listened to me and the customers I
worked with, I wouldn't need to work. You've either got an axe to grind or
don't have a clue.
Thanks,
Kent Tegels
http://staff.develop.com/ktegels/
|||On Fri, 13 Oct 2006 02:03:09 +0000 (UTC), Kent Tegels
<ktegels@.develop.com> wrote:
in <b87ad74a0568c8bc58f4dcddd0@.news.microsoft.com>

>Hello susiedba@.hotmail.com,
>s> Dude, Microsoft doesn't listen to customers... don't kid yourself
>Ha! I had a nickle for everytime they listened to me and the customers I
>worked with, I wouldn't need to work. You've either got an axe to grind or
>don't have a clue.
>Thanks,
>Kent Tegels
>http://staff.develop.com/ktegels/
>
And you clearly don't have any code assets in VB6 :: no forward
migration path other than a complete rewrite. And SQL Server 2000 won't
be supported on Vista. It seems yours is a rather myopic view.
Stefan Berglund
|||Hello Stefan,
SB> And you clearly don't have any code assets in VB6 :: no forward
SB> migration path other than a complete rewrite.
Yep, I woke and smelled the coffee early. All 40+ of my VB4/VB5/VB6 applications
are now running faster and more reliably in .NET, most of them since late
2003. I'm sorry if *you* are stuck in the stone ages, but frankly, *you*
made that decision.
SB> And SQL Server 2000
SB> won't be supported on Vista. It seems yours is a rather myopic
SB> view.
Yawn. I hear very few of my customers or users even talking about adopting
Vista anytime soon -- there's nothing in it that's an immediate driver for
them. I am hearing chatter about IIS7, so *maybe* Longhorn looks to be painful
for them. Of course, they still have the option of running on Server 2003
R2 until they are migrated to SQL 2005.
So I'm not so sure that I'm the only one that's suffering from myopia, Stefan.

Thanks,
Kent Tegels
http://staff.develop.com/ktegels/

Opportunity to provide feedback on performance improvements in SQL Server...

Please consider giving your feedback or suggestions on the top 5 OLTP and
data warehouse performance improvments you would like to see in the next
version of SQL Server. Please use the links below to provide your comments.
http://blogs.msdn.com/sqltips/archi...QL.aspx

http://blogs.msdn.com/sqltips/archi...ps/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.Dude, Microsoft doesn't listen to customers... don't kid yourself
Umachandar Jayachandran [MS] wrote:[vbcol=seagreen]
> Please consider giving your feedback or suggestions on the top 5 OLTP and
> data warehouse performance improvments you would like to see in the next
> version of SQL Server. Please use the links below to provide your comments
.
> http://blogs.msdn.com/sqltips/archi...QL.as
px
> http://blogs.msdn.com/sqltips/archi...QL.aspx

> Thanks
> Umachandar Jayachandran
> Microsoft SQL Server Performance Team
> SQL Server Engine Team Tips Blog at
> http://blogs.msdn.com/sqltips/default.aspx
> This posting is provided "AS IS" with no warranties, and confers no rights.[/vbcol
]|||Hello susiedba@.hotmail.com,
s> Dude, Microsoft doesn't listen to customers... don't kid yourself
Ha! I had a nickle for everytime they listened to me and the customers I
worked with, I wouldn't need to work. You've either got an axe to grind or
don't have a clue.
Thanks,
Kent Tegels
http://staff.develop.com/ktegels/|||On Fri, 13 Oct 2006 02:03:09 +0000 (UTC), Kent Tegels
<ktegels@.develop.com> wrote:
in <b87ad74a0568c8bc58f4dcddd0@.news.microsoft.com>

>Hello susiedba@.hotmail.com,
>s> Dude, Microsoft doesn't listen to customers... don't kid yourself
>Ha! I had a nickle for everytime they listened to me and the customers I
>worked with, I wouldn't need to work. You've either got an axe to grind or
>don't have a clue.
>Thanks,
>Kent Tegels
>http://staff.develop.com/ktegels/
>
And you clearly don't have any code assets in VB6 :: no forward
migration path other than a complete rewrite. And SQL Server 2000 won't
be supported on Vista. It seems yours is a rather myopic view.
Stefan Berglund|||Hello Stefan,
SB> And you clearly don't have any code assets in VB6 :: no forward
SB> migration path other than a complete rewrite.
Yep, I woke and smelled the coffee early. All 40+ of my VB4/VB5/VB6 applicat
ions
are now running faster and more reliably in .NET, most of them since late
2003. I'm sorry if *you* are stuck in the stone ages, but frankly, *you*
made that decision.
SB> And SQL Server 2000
SB> won't be supported on Vista. It seems yours is a rather myopic
SB> view.
Yawn. I hear very few of my customers or users even talking about adopting
Vista anytime soon -- there's nothing in it that's an immediate driver for
them. I am hearing chatter about IIS7, so *maybe* Longhorn looks to be painf
ul
for them. Of course, they still have the option of running on Server 2003
R2 until they are migrated to SQL 2005.
So I'm not so sure that I'm the only one that's suffering from myopia, Stefa
n.

Thanks,
Kent Tegels
http://staff.develop.com/ktegels/

Opportunity to provide feedback on performance improvements in SQL Server...

Please consider giving your feedback or suggestions on the top 5 OLTP and
data warehouse performance improvments you would like to see in the next
version of SQL Server. Please use the links below to provide your comments.
http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_OLTP_PERF_IMP_NEXT_SQL.aspx
http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_DW_PERF_IMP_NEXT_SQL.aspx
Thanks
Umachandar Jayachandran
Microsoft SQL Server Performance Team
SQL Server Engine Team Tips Blog at
http://blogs.msdn.com/sqltips/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.Dude, Microsoft doesn't listen to customers... don't kid yourself
Umachandar Jayachandran [MS] wrote:
> Please consider giving your feedback or suggestions on the top 5 OLTP and
> data warehouse performance improvments you would like to see in the next
> version of SQL Server. Please use the links below to provide your comments.
> http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_OLTP_PERF_IMP_NEXT_SQL.aspx
> http://blogs.msdn.com/sqltips/archive/2006/09/20/TOP_5_DW_PERF_IMP_NEXT_SQL.aspx
> Thanks
> Umachandar Jayachandran
> Microsoft SQL Server Performance Team
> SQL Server Engine Team Tips Blog at
> http://blogs.msdn.com/sqltips/default.aspx
> This posting is provided "AS IS" with no warranties, and confers no rights.