Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> sp_executesql fails to pick correct indexes
 

Pages: 1 2 3
Bugs & Issues
sp_executesql fails to pick correct indexes
Page:3/3 

  Print all messages in this thread  
Poster Message
Chaoyster
User



Location:
Canada
Joined on:
23-Mar-2011 20:31:38
Posted:
40 posts
# Posted on: 04-May-2011 22:35:22.  
Just wondering if the fix changes have been made in version 3.1. Can you confirm it?
  Top
JohnL
User



Location:
Tucson, USA
Joined on:
07-Oct-2005 19:18:13
Posted:
44 posts
# Posted on: 04-May-2011 23:16:08.  
I have not converted the problematic project to the 3 series because the hack continues to work for my client on 2.x. I have updated other clients to the 3 series successfully, so this is the only obstacle I have to doing so.

With each update of SQL I hope the problem will go away (or I can recompute statistics or improve indexes or *something*) but so far disappointment and continued usage of my inherited adapter for a handful of problem children queries.

All that is a long-winded way to say "hoping it has been implemented, but I have no idea".


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37860 posts
# Posted on: 05-May-2011 09:17:18.  
Chaoyster wrote:
Just wondering if the fix changes have been made in version 3.1. Can you confirm it?

It wasn't added. We're looking into adding to the next v3.x release, but can't promise anything. The main issue is that it's not always sufficient to do things differently to make this work and ultimately, it IS a bug in sqlserver, so MS should fix this. We can do work to provide a workaround but that workaround isn't always sufficient and also it's hard to test whether it works as it should...

@JohnL : disappointed because we didn't implement something or disappointed because microsoft didn't fix the bug in the first place? We can't take the blame for Microsoft's mess. The only thing we can do is provide a workaround which might work in most cases, but that's it.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
JohnL
User



Location:
Tucson, USA
Joined on:
07-Oct-2005 19:18:13
Posted:
44 posts
# Posted on: 05-May-2011 17:54:40.  
Otis wrote:
Chaoyster wrote:
Just wondering if the fix changes have been made in version 3.1. Can you confirm it?

It wasn't added. We're looking into adding to the next v3.x release, but can't promise anything. The main issue is that it's not always sufficient to do things differently to make this work and ultimately, it IS a bug in sqlserver, so MS should fix this. We can do work to provide a workaround but that workaround isn't always sufficient and also it's hard to test whether it works as it should...

@JohnL : disappointed because we didn't implement something or disappointed because microsoft didn't fix the bug in the first place? We can't take the blame for Microsoft's mess. The only thing we can do is provide a workaround which might work in most cases, but that's it.


I should have made it very clear that my disappointment is with Microsoft. (The key phrase: "With each update of SQL I hope the problem will go away".) The bug is noted (in multiple forms and against every version since 2005) in Microsoft's bug report systems. Just take a tour of Microsoft Connect and you will see a broken trail of "Won't Fix" closed reports on the issue (in various forms). I honestly think Microsoft doesn't know how to approach the problem at all and thus blows it off since there are workarounds available.

Having a functional workaround in 2.X means I won't upgrade that client to LLBLGen 3.X until there is a workaround available. Microsoft won't fix this anytime soon, so I do keep hoping that something will be exposed that will allow me to upgrade, but I understand that fixing 3rd party bugs isn't your responsibility.


  Top
Chaoyster
User



Location:
Canada
Joined on:
23-Mar-2011 20:31:38
Posted:
40 posts
# Posted on: 05-May-2011 19:48:16.  
Thanks guys, I do have the hack code implemented in my 2.x version, and it is working just fine for us. but we are going to update to version 3.1 next month, please confirm that the hack code is still going to work with version 3.1.

Thanks
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37860 posts
# Posted on: 05-May-2011 20:28:51.  
Thanks Regular Smiley

To my knowledge the workaround / hack still works in v3, please confirm if this isn't the case.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
carni4
User



Location:

Joined on:
09-Aug-2010 20:05:04
Posted:
20 posts
# Posted on: 06-May-2011 07:43:47.  
Otis wrote:
Thanks Regular Smiley

To my knowledge the workaround / hack still works in v3, please confirm if this isn't the case.


Workaround continues to work just fine for us in v3.
  Top
JohnL
User



Location:
Tucson, USA
Joined on:
07-Oct-2005 19:18:13
Posted:
44 posts
# Posted on: 10-May-2011 23:50:09.  
Otis wrote:
Thanks Regular Smiley

To my knowledge the workaround / hack still works in v3, please confirm if this isn't the case.


I have converted and it is true. I was confused because of an old post that said "There's one caveat: in v3 we're moving towards a DbProviderFactory approach, so your sqlclient specific code will fail." ( http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=13271 )

It appears that change didn't happen in a way that breaks the code, so I am happy. I had avoided the upgrade simply because it wasn't mission critical to update that provider and I had that stuck in my head.


  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8108 posts
# Posted on: 11-May-2011 04:35:12.  
JohnL wrote:
Otis wrote:
Thanks Regular Smiley

To my knowledge the workaround / hack still works in v3, please confirm if this isn't the case.


I have converted and it is true. I was confused because of an old post that said "There's one caveat: in v3 we're moving towards a DbProviderFactory approach, so your sqlclient specific code will fail." ( http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=13271 )

It appears that change didn't happen in a way that breaks the code, so I am happy. I had avoided the upgrade simply because it wasn't mission critical to update that provider and I had that stuck in my head.

Good to know that Regular Smiley Thanks for the feedback.
David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Pages: 1 2 3  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.