SQL != SQL...
-
Maybe when I retire?
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
I don't think so. At that time, extensive usage of both systems during your carreer will have caused severe brain damages, displacing the moral pain to a physical, unsustainable pain. Better stick to Excel as early as possible ;P
I never finish anyth
-
Very true, but some people think it just does not feel right if it is not as complicated and convoluted as possible. Browsers, CSS, JavaScript HTMl, throw them all away and build a native client where ever possible. Then you will certainly have a better UI. As for the databases, perhaps you should use a ORM as abstraction. Then you can be fairly independent of the actual database that is used. At the price (as someone already noted) that you will do everybody a favor and not do any more presentation layer stuff in the data layer.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.CDP1802 wrote:
perhaps you should use a ORM as abstraction
Works fine for CRUD, but...
Wrong is evil and must be defeated. - Jeff Ello
-
So I've been doing Oracle development, coming from SQL Server. Simple string concatenation, which is + everywhere, is || in Oracle. A little research and || seems to be the ANSI standard, which makes sense as 2 || 'A' is now unambiguous '2A' (and not a conversion error). But now I want to write a simple SELECT statement which would work in both Oracle and SQL Server. Oracle doesn't support + and SQL Server doesn't support ||, however both support CONCAT. Seems too easy for something that's uneasy already, and indeed it is... SELECT CONCAT('A', 'B') FROM TABLE works in Oracle and SQL Server. SELECT CONCAT('A', 'B', 'C') FROM TABLE works only in SQL Server... Seems like the only thing that works in both databases is CONCAT('A', CONCAT('B', 'C')). And that seems like the only reasonable solution is to write two different queries, one for Oracle and one for SQL Server because it's just too friggin difficult to implement a standard FRIGGIN STRING CONCATENATION!!! X| When does the hurting stop? :((
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
That's why I use a SQL builder. SQL - it's not Structured, it's not just Query, and it's not a Language. How the f*** did it get that acronym? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
So I've been doing Oracle development, coming from SQL Server. Simple string concatenation, which is + everywhere, is || in Oracle. A little research and || seems to be the ANSI standard, which makes sense as 2 || 'A' is now unambiguous '2A' (and not a conversion error). But now I want to write a simple SELECT statement which would work in both Oracle and SQL Server. Oracle doesn't support + and SQL Server doesn't support ||, however both support CONCAT. Seems too easy for something that's uneasy already, and indeed it is... SELECT CONCAT('A', 'B') FROM TABLE works in Oracle and SQL Server. SELECT CONCAT('A', 'B', 'C') FROM TABLE works only in SQL Server... Seems like the only thing that works in both databases is CONCAT('A', CONCAT('B', 'C')). And that seems like the only reasonable solution is to write two different queries, one for Oracle and one for SQL Server because it's just too friggin difficult to implement a standard FRIGGIN STRING CONCATENATION!!! X| When does the hurting stop? :((
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
So I've been doing Oracle development, coming from SQL Server. Simple string concatenation, which is + everywhere, is || in Oracle. A little research and || seems to be the ANSI standard, which makes sense as 2 || 'A' is now unambiguous '2A' (and not a conversion error). But now I want to write a simple SELECT statement which would work in both Oracle and SQL Server. Oracle doesn't support + and SQL Server doesn't support ||, however both support CONCAT. Seems too easy for something that's uneasy already, and indeed it is... SELECT CONCAT('A', 'B') FROM TABLE works in Oracle and SQL Server. SELECT CONCAT('A', 'B', 'C') FROM TABLE works only in SQL Server... Seems like the only thing that works in both databases is CONCAT('A', CONCAT('B', 'C')). And that seems like the only reasonable solution is to write two different queries, one for Oracle and one for SQL Server because it's just too friggin difficult to implement a standard FRIGGIN STRING CONCATENATION!!! X| When does the hurting stop? :((
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
That's why I use a SQL builder. SQL - it's not Structured, it's not just Query, and it's not a Language. How the f*** did it get that acronym? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
It is indeed just Query, the rest is DDL[^] and DML[^] The other two I'll pin down as opinions. :)
Wrong is evil and must be defeated. - Jeff Ello
-
CDP1802 wrote:
perhaps you should use a ORM as abstraction
Works fine for CRUD, but...
Wrong is evil and must be defeated. - Jeff Ello
Yes, and most things where CRUD does not work are the direct road to hell. I have seen many failed 'dynamic' SQL thingies and every time the 'creators' finally noticed that they could not swim when they were in the middle of the ocean. I'm patching up another interesting creation right now. Each table in the database has more triggers than an average piece of sh.t . Not just 'normal' triggers, if there is such a thing. Those triggers contain real application logic and also try to do everything at once, triggering even more triggers. The whole avalanche is stopped by setting special columns in the data rows. Now, I need to change a value in a primary key of one row, which usually means deleting and then inserting the row with its new key. If I do that, the wrong triggers will start triggering and everything goes to hell (GOTO is very bad). Our geniuses did an update on the data row with the new key and then the (hopefully) right triggers will take over. The problem is that I really use an ORM and updating on a new primary key value will not cause an error, but also update nothing. There hopefully is a special place in hell reserved for those people.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
So I've been doing Oracle development, coming from SQL Server. Simple string concatenation, which is + everywhere, is || in Oracle. A little research and || seems to be the ANSI standard, which makes sense as 2 || 'A' is now unambiguous '2A' (and not a conversion error). But now I want to write a simple SELECT statement which would work in both Oracle and SQL Server. Oracle doesn't support + and SQL Server doesn't support ||, however both support CONCAT. Seems too easy for something that's uneasy already, and indeed it is... SELECT CONCAT('A', 'B') FROM TABLE works in Oracle and SQL Server. SELECT CONCAT('A', 'B', 'C') FROM TABLE works only in SQL Server... Seems like the only thing that works in both databases is CONCAT('A', CONCAT('B', 'C')). And that seems like the only reasonable solution is to write two different queries, one for Oracle and one for SQL Server because it's just too friggin difficult to implement a standard FRIGGIN STRING CONCATENATION!!! X| When does the hurting stop? :((
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
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). :mad: 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 // (The number of parameters)
)]
[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// Other members as required
}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.
-
I had fun with SQL SUBSTRING the other day...WTE is it 1 based? :laugh:
"Go forth into the source" - Neal Morse
Because
CHARINDEXis? :-D -
It'll get even funnier when you realize that even when the SQL is completely compatible, the results may not be. For example: Oracle doesn't have an empty string.
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
Oracle doesn't have
A
GUIDtype. :sigh: In some databases a one-byte integer is signed; in others it's unsigned. :(( -
Yes, and most things where CRUD does not work are the direct road to hell. I have seen many failed 'dynamic' SQL thingies and every time the 'creators' finally noticed that they could not swim when they were in the middle of the ocean. I'm patching up another interesting creation right now. Each table in the database has more triggers than an average piece of sh.t . Not just 'normal' triggers, if there is such a thing. Those triggers contain real application logic and also try to do everything at once, triggering even more triggers. The whole avalanche is stopped by setting special columns in the data rows. Now, I need to change a value in a primary key of one row, which usually means deleting and then inserting the row with its new key. If I do that, the wrong triggers will start triggering and everything goes to hell (GOTO is very bad). Our geniuses did an update on the data row with the new key and then the (hopefully) right triggers will take over. The problem is that I really use an ORM and updating on a new primary key value will not cause an error, but also update nothing. There hopefully is a special place in hell reserved for those people.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.CDP1802 wrote:
more triggers than an average piece of sh.t
I think you mean "more triggers than Texas".
-
Very true, but some people think it just does not feel right if it is not as complicated and convoluted as possible. Browsers, CSS, JavaScript HTMl, throw them all away and build a native client where ever possible. Then you will certainly have a better UI. As for the databases, perhaps you should use a ORM as abstraction. Then you can be fairly independent of the actual database that is used. At the price (as someone already noted) that you will do everybody a favor and not do any more presentation layer stuff in the data layer.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.CDP1802 wrote:
perhaps you should use a ORM as abstraction
Frack no! That just makes things worse! :wtf:
-
CDP1802 wrote:
more triggers than an average piece of sh.t
I think you mean "more triggers than Texas".
I used to live there. Don't mess with Texas :-)
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
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). :mad: 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 // (The number of parameters)
)]
[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// Other members as required
}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... :~
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
That's why I use a SQL builder. SQL - it's not Structured, it's not just Query, and it's not a Language. How the f*** did it get that acronym? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
:thumbsup: :laugh:
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I don't think so. At that time, extensive usage of both systems during your carreer will have caused severe brain damages, displacing the moral pain to a physical, unsustainable pain. Better stick to Excel as early as possible ;P
I never finish anyth
phil.o wrote:
severe brain damages
Causing you to miss the Reply button and hit Email instead? ;p
phil.o wrote:
Better stick to Excel as early as possible ;-P
Better, I started in VB! :D
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
So what you are saying is T-SQL <> PL/SQL? :)
Mongo: Mongo only pawn... in game of life.
Why do they need the T- and PL/ anyway, at least for simple queries...
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
phil.o wrote:
severe brain damages
Causing you to miss the Reply button and hit Email instead? ;p
phil.o wrote:
Better stick to Excel as early as possible ;-P
Better, I started in VB! :D
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
Causing you to miss the Reply button and hit Email instead? ;-P
I wondered why I had to reply twice ^^ Now I know.
Sander Rossel wrote:
Better, I started in VB! :-D
Beware! VB is extremely dangerous. VB destroys ozone layer. VB causes cancer and other funny diseases.
I never finish anyth
-
Jörgen Andersson wrote:
Oracle doesn't have
A
GUIDtype. :sigh: In some databases a one-byte integer is signed; in others it's unsigned. :((PIEBALDconsult wrote:
A
GUIDtypeSyntactic sugar. Use
myguid RAW(16) default SYS_GUID()Or rather, don't use them at all. The only serious place where GUIDs have the edge over sequences is on distributed systems.Wrong is evil and must be defeated. - Jeff Ello
-
Yes, and most things where CRUD does not work are the direct road to hell. I have seen many failed 'dynamic' SQL thingies and every time the 'creators' finally noticed that they could not swim when they were in the middle of the ocean. I'm patching up another interesting creation right now. Each table in the database has more triggers than an average piece of sh.t . Not just 'normal' triggers, if there is such a thing. Those triggers contain real application logic and also try to do everything at once, triggering even more triggers. The whole avalanche is stopped by setting special columns in the data rows. Now, I need to change a value in a primary key of one row, which usually means deleting and then inserting the row with its new key. If I do that, the wrong triggers will start triggering and everything goes to hell (GOTO is very bad). Our geniuses did an update on the data row with the new key and then the (hopefully) right triggers will take over. The problem is that I really use an ORM and updating on a new primary key value will not cause an error, but also update nothing. There hopefully is a special place in hell reserved for those people.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.Anyone using triggers for anything else than logging, or with any recursion whatsoever, should get publically flogged. Just a personal opinion.
Wrong is evil and must be defeated. - Jeff Ello
