|
Because CHARINDEX is?
modified 8-Oct-15 19:19pm.
|
|
|
|
|
Sander Rossel wrote: When does the hurting stop?
Generally, the hurt lessens with each paycheck.
I use many different database systems. I also have to deal with the various ways of wrapping table and column names in the various databases: [] , "" , `` , etc. And parameter prefices: @ , : .
But it's Caché with is lack of operator precedence that wins the prize as worst (yes, worse than Access and Excel).
Anyway... now and again I work on a technique to deal with these issues. My current technique looks a bit like this:
internal enum SQL
{
[System.ComponentModel.DescriptionAttribute("Get a User record by Name")]
[PIEBALD.Attribute.SqlServerStatementAttribute
(
@"
SELECT [blah] , [blah] , [blah] FROM [UserTable] WHERE [Name]=@Param0
"
,
1
)]
[PIEBALD.Attribute.OracleStatementAttribute
(
@"
SELECT ""blah"" , ""blah"" , ""blah"" FROM ""UserTable"" WHERE ""Name""=:Param0
"
,
1
)]
[PIEBALD.Attribute.MySqlStatementAttribute
(
@"
SELECT `blah` , `blah` , `blah` FROM `UserTable` WHERE `Name`=@Param0
"
,
1
)]
GetUserByName
}
This has the added benefit that it keeps all the various versions of the SQL together rather than having separate files or classes for each type of database and never knowing whether or not you are keeping them maintained properly.
Then in the application, I need refer only to the enumeration members, and my framework will select the correct version of the SQL for the particular ADO.net provider in use at the moment. (Yes, I might write yet another Data Access article.)
Very few applications actually need this, but it's good exercise.
|
|
|
|
|
PIEBALDconsult wrote: Very few applications actually need this, but it's good exercise. And fun!
Unless, of course, you need to get things done quick...
|
|
|
|
|
All three work with the ANSI/ISO standard which is "" . MySQL have to be set in ANSI mode though.
Parameter prefices is a real pain though, especially the ansi standard ? which is positional only.
|
|
|
|
|
PIEBALDconsult wrote: wrapping table and column names
He/She who uses spaces in table/field names should be publicly flogged! Even in this day and age, one of the items on my TODO list is reverse engineering a report a client sent to create a data pull from their 'new' Access 97 based inventory system and it's chock full of spaces in table and field names. Whenever possible, I avoid unnecessary wrapping...but that's just me.
"Go forth into the source" - Neal Morse
|
|
|
|
|
I'm doing a lot of ETL/import, I see it all -- SPACEs, ASTERISKs, SLASHes, DOTs, reserved words, etc. I prefer to strike back first and wrap everything.
|
|
|
|
|
Sander Rossel wrote: When does the hurting stop?
When you stop expecting Microsoft to conform to any standard other than what feels good to them this week, the pain will subside. Not stop, but subside some...
Will Rogers never met me.
|
|
|
|
|
Sander Rossel wrote: When does the hurting stop?
When you start using NoSQL, No SQL at all
|
|
|
|
|
When you stop writting SQL and let your ORM handle it!
Eric
|
|
|
|
|
Sounds like a good time for some dynamic sql. I know lots/most folks dis the idea of such, but it certainly has its place imho.
|
|
|
|
|
|
Sander Rossel wrote: But now I want to write a simple SELECT statement which would work in both Oracle and SQL Server.
Why is that important?
If you're running some kind of application to interface with the database, seems like the call to the database should just invoke a sproc (for example--maybe a query, whatever).
You have the same named sproc on two instances, but they work differently. The code layer is effectively calling an interface (i.e., "whatever I'm connected to, execute the 'selectMyStuff' sproc"), and each database is the concrete implementation of that interface.
This is a simple example, but what if the databases had completely different structures? You wouldn't expect to deploy the same SQL to both, you'd have to write custom procedures which happened to take the same parameters and return the same result set (i.e., implement the 'interface'), even though they perform that operation in significantly different ways.
|
|
|
|
|
Yeah, normally I'd do that, but this time I'm generating the query client side
Anyway, it's not all that important, I should abstract away such stuff and implement it for each database anyway.
I was just amazed that something so simple can't be done uniformly by two of the biggest databases that both work with the same language that has an ANSI standard...
|
|
|
|
|
Movie Quote Of The Day
I always felt that the old Bond films were only as good as the villain. As a child, I rather fancied a futuristic colorful megalomaniac.
Which movie?
|
|
|
|
|
The Donald Trump Story?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
This isn't that kind of movie.
|
|
|
|
|
Iron Man
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
|
|
|
|
|
V. wrote: good as the villain
The ain't always that bad, the Villians.
|
|
|
|
|
Inception : James Bond watches James Bond with James Bond in a future past / past future scenario doing his jobs but doing it somehow diffrent and crashing the whole universe because the villian was bad.
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Harry Potter & the Gentleman spy
Regards,
Palash
|
|
|
|
|
Megamind
Mongo: Mongo only pawn... in game of life.
|
|
|
|
|
The League of Extraordinary Gentlemen
Software Zen: delete this;
|
|
|
|
|
One of my favorites!
Will Rogers never met me.
|
|
|
|
|
Vincent's dotty - painting an Italian flower with a sick number one point one oh oh oh?(11)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
You're dotty if you think we're going to give you the answer. I do like the ending to the clue though - very clever.
|
|
|
|