Just wondering if the fix changes have been made in version 3.1. Can you confirm it?

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".

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.

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.

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

Thanks

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

Otis wrote:

Thanks

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.

Otis wrote:

Thanks

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.

JohnL wrote:

Otis wrote:

Thanks

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 Thanks for the feedback.