PDA

View Full Version : SQL placeholders



AtW
27th November 2006, 11:28
Are way too limited!

Why can't I do this (bold are bits used for placing params):

select * from TableName_@param1 where Domain='@param2'

:tantrum:

DimPrawn
27th November 2006, 11:33
Now you are just being silly.

SQL has an ANSI std and that is not in it.

You can do it using proprietary extensions that allow dynamic SQL execution and other well know means.

Watch out for SQL injection flaws when using dynamic SQL.

AtW
27th November 2006, 11:37
This functionality is not exposed to anything that can inject that kind of stuff, @param1 is integer anyway.

Seems like I will have to manually interpolate @param1 here and then prepare statement using placeholder in place of @param2 - SQLite shown to use a LOT of CPU preparing statements all the time because they used crappy slow .NET's regular expressions. :tantrum:

DimPrawn
27th November 2006, 11:38
Which SQLite provider are you using? The Finisar one or the one for .NET 2.0?

AtW
27th November 2006, 11:41
I am still on Finisar, but I believe placeholders wise it is fundamendal issue that they can't have the kind of stuff above - they want to compile statement fully, so table name should be known in advance, will have to change it the same way I do now for each query, but then prepare it (once table name is known during batch inserts) and use that prepared statement.

Also ?nnn placeholders don't seem to work in it :bang:

DimPrawn
27th November 2006, 12:06
I am still on Finisar, but I believe placeholders wise it is fundamendal issue that they can't have the kind of stuff above - they want to compile statement fully, so table name should be known in advance, will have to change it the same way I do now for each query, but then prepare it (once table name is known during batch inserts) and use that prepared statement.

Also ?nnn placeholders don't seem to work in it :bang:

Haven't you just answered your own question of why?

AtW
27th November 2006, 12:08
Haven't you just answered your own question of why?

They could have made it more powerful while still providing benefits of parsing query only once, just leave table name resolves and stuff like that until the last moment.

DimPrawn
27th November 2006, 12:09
They could have made Biztalk able to use xls files but they didn't.

NOW GET OVER IT!!!

AtW
27th November 2006, 12:10
Ze swines.

Joe Black
27th November 2006, 18:40
They could have made Biztalk able to use xls files but they didn't.Yes they did. XLS files are only a custom adaptor away. :)

DimPrawn
27th November 2006, 18:44
Wow Joe, that's great news.

So all anyone has to do to use Microsoft Biztalk with xls files is to resort to implementing their own custom adaptor?

That's so thoughtful of them not to put an obvious piece of functionality into their product. Hey let's let everyone reinvent the wheel! Why give any adaptors at all, feck, we'll all implement them in C#!!! It's fun and the project has all the time in the world!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I mean, what are the chances that anyone has data in xls files? It's not like you would expect Mictosoft Biztalk to be able to consume Microsoft XL files out of the box is it. No we'll resort to low level coding everything! More lines of code, that's the answer! I mean, testers are free and adding custom code can only be a good thing, right?

Thank goodness for Biztalk!

It's all so easy and "feature rich"!

Worth every penny of the £10,000 processor license!!!

:rolleyes:

AtW
27th November 2006, 18:48
Worth every penny of the £10,000 processor license!!!

And your invoice was for how much again...

DimPrawn
27th November 2006, 18:50
I'm only adding about £100K to the cost of the project, so cheap.

AtW
27th November 2006, 18:51
Then paying a few grand for custom adapter should not be a problem then, perhaps you can sacrifice some of your fat threaded-like margin for that? :rolleyes:

DimPrawn
27th November 2006, 18:53
I'm not implementing it mate. A consultancy that charges £1500/day per developer is.

Makes my cost look like petty cash.

AtW
27th November 2006, 18:54
£1500 per day, it must hurt to pay income tax on that :eek:

DimPrawn
27th November 2006, 19:00
The consultancy doesn't pay income tax on that. Probably all ends up in an company registered offshore, and a donation to New Labour ensures the tax man turns a blind eye. Get real. Income tax. :rolleyes:

Joe Black
27th November 2006, 19:01
Why give any adaptors at all, feck, we'll all implement them in C#!!! It's fun and the project has all the time in the world!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I mean, what are the chances that anyone has data in xls files? It's not like you would expect Mictosoft Biztalk to be able to consume Microsoft XL files out of the box is it. No we'll resort to low level coding everything! More lines of code, that's the answer!Speaking of which, not having used the latest Biz, what's the story with Orchestrations, since that was more a C flat with the 2004 version.

PS: Yes, on a major project I worked on we did indeed have to build everything, adaptors, pipeline components, custom calls from Orchestrations and even a replacement for the HAT.

Still, it was the word 'Biztalk' which managed to secure them the out of their league project in the first place. :eek:

DimPrawn
27th November 2006, 19:02
2006 is 2004 version with a bit of gloss. Same story.