You are viewing avatraxiom

To The Side

Oracle-itis

Most Oracle DBAs, it seems, have never used any other database system. Or they have, but it was in Ancient Times before there was a SQL Standard or something. (By the way, that would have to have been before 1992, when SQL-92 was made. Hi, welcome to the 90's!)

I don't think Oracle is a totally worthless product. I hear that it's good for carrier-grade high-availability. Of course, I've also heard that it's fairly easy to crash it, so hey. I know that my Oracle install stopped working once just because I had added, oh, a fifth database to it. Apparently you have to explicitly tell Oracle (with a very cryptic command that's specific to just your system, because it involves filesystem paths) that you want to have more than about five databases.

Okay, so I'm biased and I have an unusual viewpoint. I started out using MS SQL Server, then PostgreSQL, then learned MySQL, and now I've been involved in reviewing all the Oracle code for Bugzilla 3.2. (Side note: I've used other DB systems, also.) Most people aren't porting a shipping ANSI SQL application to many different databases. But I am, which means I've learned a lot about all the databases. So here's my experience:

In terms of features and sanity, PostgreSQL has always been hands-down the best. It was missing fulltext indexes until 8.3, but now it's got those. Of all the popular database systems in existence, PostgreSQL does the best for ANSI compliance, and even though the ANSI SQL standard is very long, it's generally much saner than anything that people come up with in-house.

I remember when I had to learn MySQL after using PostgreSQL, I was like, "What is all this?" MySQL got a lot better over the years, though, and MySQL 5 is generally pretty good.

Oracle, though, is downright strange. Now, because most Oracle DBAs don't have a lot of experience with other databases (or at least not with ANSI SQL) I think they accept a lot of these strangenesses as normal. So in case there are some curious Oracle DBAs out there, here are some of the really weird things that Oracle does:

  1. In every other database out there, an empty string and NULL are not the same thing. The Oracle SQL Reference tells you not to treat an empty string like a NULL (because they might change that behavior in the future), but they don't actually give you any way to not treat it like a NULL!
  2. You can't SELECT a CLOB (that's a TEXT field to the rest of the world) if there's a GROUP BY clause. What?
  3. Subtracting one month from March 29, 2007 gives you...February 29, 2007, a day that never existed. In fact, because it never existed, Oracle throws an error if you do that. Other databases just give you February 28 (or March 1 if you're adding, I think).
  4. Oracle doesn't support the SQL "LIMIT" clause, it uses something weird in the WHERE clause instead.
  5. Oracle has a hard limit on IN clauses of 1000 items. But it doesn't complain if you OR together multiple IN clauses with 1000 items each...
  6. Oracle doesn't allow identifiers to be longer than 32 characters (index names, column names, etc.).
  7. Oracle doesn't support ON UPDATE CASCADE for foreign keys. Even MySQL supports that, nowadays.

I suppose that would also be a helpful list for anybody porting an ANSI SQL app to Oracle, since that's all the really weird things we encountered in Oracle. There were also lots of sensible, normal differences between Oracle and other DBs--some functions are named differently, etc. That's all fine with me. What I listed above are the really weird things that you wouldn't expect.

By the way, this is not to say that I'm not really thankful for Oracle Corp.'s help with Bugzilla 3.2, and all the great work that Xiaoou has done with us to help us support Oracle--that's been wonderful, I totally appreciate it.

This was my first Oracle experience, and with everything I'd seen about it, marketing-wise, I expected it to do backflips and jump through hoops of fire. I was surprised to discover that, from a developer's perspective, the two popular open-source solutions (PostgreSQL and MySQL) are actually way better. That's true even from a sysadmin perspective--I find them both way easier to administer and install than Oracle (which is kind of a nightmare to admin and install).

Oracle DBAs tend to react as though the nightmare and the strangeness are the most normal thing in the world. "Oh, yes, you just have to flip the twiddly bit and jump up and down three times. Wasn't that obvious?" Much like the administrators of any Rube Goldberg machine, Oracle DBAs have been educated to accept a complexity that is not actually native to relational databases.

Anyhow, this is all quite surprising, since Oracle has millions of dollars, hundreds of developers, and has had years and years to develop their product, and it isn't as full-featured or easy to use as two products made by some little open-source projects.

-Max
Tags: ,

Comments

Oracle requires pretty beefy servers for not much performance, and requires lots of support contracts from Oracle to actually maintain it in a working state. I know a few MMOs written on Oracle and everybody says never again (although, to be fair, relational DBs need a lot of tweaking to support an MMO).

My boss is actually a former Oracle VP :P.
Hahahaha. :-) Yeah, none of that surprises me at all. :-)

-Max

(Anonymous)

>Oracle requires pretty beefy servers for not much performance, and requires lots of support contracts from >Oracle to actually maintain it in a working state.

Are you serious? I'm running Oracle on a laptop.

Oracle does not *require* a support contract. You might *need* one, but that is not the same thing.
Well, fair enough.

As a comparison, I'm not even sure you can get a support contract for PostgreSQL, but I've never needed one, nor do I know anybody who's ever needed one--it's very simple to administer.

-Max

(Anonymous)

Check for errors before publishing

I always thought that june 29 minus 6 months will be december 29 of the year before.

Re: Check for errors before publishing

Hey thanks! I fixed it.

-Max

(Anonymous)

I thought I'd compare with Gupta SQLBase v6 (so not the latest version), a desktop database that I had to use for several projects:

  1. In every other database out there, an empty string and NULL are not the same thing.
    In SQLBase, an empty string is the same as NULL, but an empty LONG VARCHAR (which is a generic large BLOB/CLOB/TEXT type) is not.

  2. You can't SELECT a CLOB (that's a TEXT field to the rest of the world) if there's a GROUP BY clause. What?
    In SQLBase, you can't GROUP BY a LONG VARCHAR. Your best best is a subquery or a join with a view.

  3. Subtracting six months from June 29, 2007 gives you...February 29, 2007, a day that never existed. In fact, because it never existed, Oracle throws an error if you do that. Other databases just give you February 28 (or March 1 if you're adding, I think).
    In SQLBase June 29, 2007 - 4 months gives you Feburary 28; October 2006 + 4 months also gives you Feburary 28.

  4. Oracle doesn't support the ANSI SQL "LIMIT" clause, it uses something weird in the WHERE clause instead.
    SQLBase has no such concept. Instead the query utility has a limit setting.

  5. Oracle has a hard limit on IN clauses of 1000 items. But it doesn't complain if you OR together multiple IN clauses with 1000 items each...
    I don't know what limit SQLBase has, if any.

  6. Oracle doesn't allow identifiers to be longer than 32 characters (index names, column names, etc.).
    SQLBase has a limit of 18 characters.

  7. Oracle doesn't support ON UPDATE CASCADE for foreign keys. Even MySQL supports that, nowadays.
    SQLBase doesn't support this either.
Wow, overall that sounds even more difficult. :-) At least it gets the date intervals right, though.

-Max

(Anonymous)

Ugghh....

I had a brief (1 month) run in with Oracle a few years back. And even that was enough to make me think "never again!".

And actually, at the time, my list of "weird and stupid things that Oracle does" was much the same as the one listed here. I already had some experience with various other database systems, and had my own set of likes/dislike for each of them. But Oracle just made me want to yell out "What? That's.... STUPID!"

Re: Ugghh....

I know...you have no idea how many times I've just made the "WTF" face while working with Oracle. :-)

-Max
SQL> select add_months(to_date('29.06.2007','dd.mm.yyyy'),-6) from dual;

ADD_MONTH
---------
29-DEC-06

SQL> select add_months(to_date('29.06.2007','dd.mm.yyyy'),-4) from dual;

ADD_MONTH
---------
28-FEB-07

SQL> select add_months(to_date('29.06.2008','dd.mm.yyyy'),-4) from dual;

ADD_MONTH
---------
29-FEB-08


wtf?
You're using ADD_MONTHS, which we can't use--we use the standard INTERVAL notation, because a lot of this involves generated SQL that might have different types of intervals, not just months. For people who just want to add months, ADD_MONTH certainly works...that's not very useful, though, for anybody writing a web application with actual end users.

-Max

Anti-Oracle-itis

We laughed about the interval arithmetic too, until we got a reply from Tom Kyte that it was a regrettable side effect of the ANSI rules that they retained for compliance:

Stop Press: Oracle Granted License To Extend February (http://oracle-wtf.blogspot.com/2006/02/stop-press-oracle-granted-license-to.html)

I haven't read the standards docs myself but as a rule I'm prepared to trust Tom Kyte. Perhaps the real WTF is that the standard contained something obviously stupid and Oracle was the only vendor not to just quietly fix it.

Re: Anti-Oracle-itis

Yeah, the SQL-92 standard contained language that you could interpret ambiguously about it, but SQL 2003 is oddly insistent about maintaining the day field when you are adding months. I think it's still ambiguous, but yeah, that's one place where I'd think that people really shouldn't stick to the standard. I can't imagine that would *ever* be a programmer's intended or desired behavior.

-Max
SQL> select add_months(to_date('29-06-2007', 'DD-MM-YYYY'), -4) from dual
2 /

ADD_MONTHS(TO_DATE('29-06-2007
------------------------------
28.02.2007

SQL> select add_months(to_date('29-06-2000', 'DD-MM-YYYY'), -4) from dual
2 /

ADD_MONTHS(TO_DATE('29-06-2000
------------------------------
29.02.2000

SQL>
Yeah, see my comment to the other responder above. :-)

-Max
So, if MySQL works this interval well, they does not support ANSI :-)

Quote:
This is Expected behavior of the SQL92 standard:


"... 3) If a immediately contains the operator + or -, then the result is effectively evaluated as follows:
.
a) Case:
.
i) If immediately contains the
operator + and the or is not negative, or if
immediately contains the operator - and the
is negative, then successive s of the
[Error: Irreparable invalid markup ('<in->') in entry. Owner must fix manually. Raw contents below.]

So, if MySQL works this interval well, they does not support ANSI :-)

Quote:
This is Expected behavior of the SQL92 standard:


"... 3) If a <datetime value expression> immediately contains the operator + or -, then the result is effectively evaluated as follows:
.
a) Case:
.
i) If <datetime value expression> immediately contains the
operator + and the <interval value expression> or <interval
term> is not negative, or if <datetime value expression>
immediately contains the operator - and the <interval term>
is negative, then successive <datetime field>s of the <in-
terval value expression> or <interval term> are added to
the corresponding fields of the <datetime value expression>
or <datetime term>.

ii) Otherwise, successive <datetime field>s of the <interval
value expression> or <interval term> are subtracted from
the corresponding fields of the <datetime value expression>
or <datetime term>.

b) Arithmetic is performed so as to maintain the integrity of
the datetime data type that is the result of the <datetime
value expression>. This may involve carry from or to the
immediately next more significant <datetime field>. If the
data type of the <datetime value expression> is TIME, then
arithmetic on the HOUR <datetime field> is undertaken modulo
24. If the <interval value expression> or <interval term> is
a year-month interval, then the DAY field of the result is
the same as the DAY field of the <datetime term> or <datetime
value expression>

c) If, after the preceding step, any <datetime field> of the
result is outside the permissible range of values for the
field or the result is invalid based on the natural rules for
dates and times, then an exception condition is raised: data
exception-datetime field overflow..."

end of quote.

ii-b there could be interpreted to be the way that MySQL and PostgreSQL work.

Do SQL-99 and SQL-2003 say the same thing about this? Nobody really conforms to just SQL-92 anymore.

-Max
ISO/IEC 9075-2:200x(E) (SQL/Foundation), January, 2002
6.30

4) In the following General Rules, arithmetic is performed so as to maintain the integrity of the
datetime data type that is the result of the or .
This may involve carry from or to the immediately next more significant . If the data type of the or is time with
or without time zone, then arithmetic on the HOUR is undertaken
modulo 24. If the or is a year-month interval, then
the DAY field of the result is the same as the DAY field of the or .
6) If a immediately contains the operator or , then the time zone component, if any, of the result is the same as the time zone component
of the immediately contained or . The UTC
component of the result is effectively evaluated as follows:

a) Case:

i) If immediately contains the operator and
the or is not negative, or if immediately contains the operator and the is negative, then successive s of the or are added to the corresponding fields of the or .

ii) Otherwise, successive s of the or
are subtracted from the corresponding fields of the or .

b) If, after the preceding step, any of the result is outside the permissible
range of values for the field or the result is invalid based on the natural rules for dates
and times, then an exception condition is raised: data exception - datetime field overflow.
So, about CLOB's. In group by select there are two choices, one - column is on group by, second - you will need to aggregate it. Neither aggregate or group by is supported with large objects. But you can select they, if you find, what CLOB's corresponds to each row, for example max(rowid):


select varb from testblob where rowid in
(select max(rowid) from testblob t
group by t.numb)


Yeah, but I don't have to do that for any other database. And doing a subselect would involve a ridiculously involved code reorganization.

-Max
"Standard ANSI SQL" is myth, i think. There are the road to Metalink :-)
No, not really. Simple docs on it are here:

http://savage.net.au/SQL/

Well, they're simple if you can read BNF.

PostgreSQL implements most of that pretty well, particularly SQL-99.

-Max
if you have access to metalink.oracle.com, check how many bugs Oracle Database has with ANSI join syntax(left outer join, etc). There bugs in result set, bugs with CBO, etc. And there are no bugs with (+) oracle join, that do similar.

(Anonymous)

no boolean

Oracle doesn't support boolean data types to the best of my knowledge. That's pretty big.

Also, try storing blobs - aaagggghhhh! - what a nightmare. Insert EMPTY_BLOB() and then update? what?

(Anonymous)

Great at marketing

Oracle is great at marketing though. A lot of decision makers don't consider the implementation their problem, which generally *is* the problem.

Re: Great at marketing

Yeah, I agree. If I felt like being particularly inflammatory, I'd say that they have a High-Availability Marketing Department. :-)

And yeah, that is unfortunate about decision makers. It's too easy to make a decision that makes you look good or sounds good but actually brings failure or difficulty to your project in the long run. I'm not saying that using Oracle is such a decision, just that such decisions are often made.

-Max

(Anonymous)

Oracle isn't that bad, despite being a nightmare to install more options than you would think have ever been used.

It has some fantastic features such as Analytical Queries and the SQL optimiser is the best I have seen for getting performance.

But only when compared with Sybase do you realise that Oracle is as a nice DB for a developer. Saying that for Commercial work, I always recommend SQL Server because an idiot can manage it, for my own things I use MYSQL because it is available with every hosting company!
Yeah. Oracle definitely has a zillion features of varying levels of neatness, you have to give it that.

Hahaha, yeah, I've heard terrible things about Sybase, too. We had some people who had to port Bugzilla to Sybase--they had to actually just remove some features from the system because they just couldn't be done on Sybase.

Installation and administration of a database system is particularly important when you're a shipping application like Bugzilla, too. Or when you're going to write an application and leave it in somebody else's hands.

And yeah, everybody has MySQL--that's another advantage for Bugzilla using it (although that wasn't my decision--it was made long before I came on the project, and it was pretty much the ONLY open-source choice back then).

-Max

(Anonymous)

Database independence is one of those myths

Even though there is a standard there is still enough room for database vendors to implement it differently. One area where you can be caught by surprise is locking and isolation levels. Stored procedure syntax is a different area. So, if you deploy an application on multiple database products you better prepare to handle them differently.

Apart from that: much of Oracle's complexity in administering it comes from the fact that this is a RDBMS which provides a load of features to be usable in a wide range of different settings. The product is complex - and it needs to be if you want to handle large data volumes 24*7 etc. If you do not need them, good for you. But if you are the DBA that has to provide persistence support for a high volume application you'll be glad that you do not have to run it on MySQL.

Re: Database independence is one of those myths

Yeah, the isolation levels stuff definitely varies widely. That all makes sense OK to me, though. That's not something I'd complain about, they're all sensible differences.

I think what I expect out of database independence is just compatibility of basic features between databases--that they all have the same basic SQL syntax, that they support subselects, UNION, and something like similar data types (although more unification of those would sure be nice). Some things (particularly things that aren't in the standard, though some also in the standards) you just can't expect to behave the same across different systems.

As far as a large-volume application running on MySQL, there are plenty of those (like lots of Google and Yahoo stuff), although they go the commodity-hardware grid route--which is probably the way that large-scale applications are going in the future anyhow, since it's much easier to expand horizontally like that then vertically with huge machines.

-Max

Re: Database independence is one of those myths

If code is written to run on any database it'll generally run very badly - the whole point of the non-standard bits in a given DB is to say "use our database because we have X which makes task Y easier/faster/cheaper".

Re: Database independence is one of those myths

No, totally untrue. Most DB performance issues are totally standard issues with indexes and schema that have nothing to do with vendor-specific features.

-Max
Comment to anonymous about blob ;-)


You can simply create temporary blob, fill it, insert into table, and delete temporary blob. It works :-)
That's pretty Rube Goldberg compared to any of the other DBs I've used, though. I understand of course that Oracle has a lot more historical compatibility requirements, and was designed much, much longer ago than any of the other systems.

-Max

(Anonymous)

1. empty string and NULL - yep that's annoying. Fixing this will make Y2K look like a walk in the park.

2. Can't SELECT a CLOB with GROUP BY clause. - Select fields have to be in the group by, so you're really saying you can't GROUP BY a clob. That isn't scalable and is really bad design, and I challenge you to provide a situation where it's actually needed. Add metadata around the clob (including say it's hash). By the way, you can use a subselect and then put your clob in the result.

3. Date arithmetic
Bogus, as others have pointed out. Use add_months.

4. ANSI SQL "LIMIT" clause
WHERE rownum < 100 is "weird"?!?! Why exactly can ANSI not allow this?

5. IN clauses of 1000 items.
Again, like most of these things in this list, it's questionable design if you need to do this. Why aren't those 1000+ things in a table?

6. 32 character identifiers.
This is annoying, I agree. I don't see why this can't be fixed easily.

7. Oracle doesn't support ON UPDATE CASCADE for foreign keys. Even MySQL supports that, nowadays.
Wow, that is an egregiously bad design practice. You should never, ever, EVER update primary keys. This feature is a bug in MySQL.


2. It was a side effect of how fulltext searching works in the databases that we were porting from. I agree that it's unlikely that you'd actually need to GROUP BY a CLOB, but I should still be able to select a CLOB and GROUP BY other fields. That is one annoying feature of the SQL Standard, actually, that SELECT fields must all be in the GROUP BY clause.

3. I need to use INTERVAL. This SQL is being generated by an application. INTERVAL works just fine in MySQL and PostgreSQL (and SQLite, I think).

4. "rownum" is not the name of any column in any table, so having it in the WHERE clause does seem a bit odd. Anyhow, LIMIT is the standard.

5. Those 1000 things are in a table. I'm getting them out of the table. This is an application, not a manually-written SQL query. I have a set of objects that have been returned from some other query, and I need to check something about them. It's an extremely common operation within the application. Anyhow, IN is just set arithmetic if there's an index, it shouldn't be that hard.

7. Yes, we never do update primary keys. However, if somebody fiddles with the database and needs to change them for some reason, it would be nice if that change cascaded. It's more useful when people are using string primary keys (something I never do, but some people do).

-Max

(Anonymous)

2. Full text search is not a feature that generic RDBMS functionality is a very good solution for. In an Oracle setting, use Oracle text. If you want something portable, use Lucene or something like it. Searching clobs to match text can really crush your database very quickly. There is no ANSI standard solution herer.

I don't know what it would mean to select somethign that isn't either grouped or aggregated. Consider something like:
select foo, bar, count(baz)
  from sometable
 group by bar

Which row in sometable would supply the value for foo, given that multiple rows may exist in the group? The only way to make this make sense is to use a subquery (inline view) with a join, like so:
select a.foo, b.cnt
  from tablea a,
       (select bar, count(*) cnt
          from sometable
         group by bar) b
 where b.bar = a.bar

Then foo could be a clob.

3. SQL is not portable. If you want to write portable db applications, you have no choice but to write an adapter layer for each RDBMS you will support. I don't know what language you are using, but Hibernate solves this problem fairly well. I gather you are writing you own SQL and not using an ORM. You should write your DAOs in such a way that you can flip out RDBMS implementations underneath to polymorph the different behaviors.

Incidentally, on my project we use Hibernate and developers code to derby on a day to day basis. We CI against derby and oracle, and QA and deploy against Oracle. To get this we basically say "absolutely no stored procedures or triggers" and we leverage the hell out of Hibernate's dialect support.

4. Had ANSI SQL done a better job, or simply done their job sooner, maybe they would describe what the leading db vendor actually does here. By the way, there's something really fishy when the market selects one vendor as the clear leader based on honest competition and then a stardards body doesn't produce something that's easy for them to migrate to. This indicates a failure within the standards process, not by Oracle.

BTW, I almost never use either construct. If you want 100 rows, open your cursor on the client and pull 100 rows. The server really doesn't care as it will do the same exectution plan with or without the knowledge of how many rows you will read.

5. Why can't you use a join? It sounds like you are issueing one SQL statement to get an intermediate result and then using it to dynamically construct a second SQL statement at runtime with the IN clause. Do this in one SQL statement using joins. This will almost certainly be more efficient.

6. No, it'd be nice if "somebody" got a nasty error and had no recourse but to fix their broken design.
Your points are all really good, but you're probably unfamiliar with the codebase I'm working on, so although in generic situations I would almost always do what you're talking about, I am constrained by the fact that this application started its life in 1998 (before there were ORMs, particularly in open source), is a shipping application, started its life on MySQL and also supports PostgreSQL (thanks to me), and has much more complex logic requirements than any other web app I've worked on.

With all that in mind, here are some of my responses:

2. In order to be performant, we have to have our fulltext criteria in the same gigantic SQL statement that the rest of our criteria are in. I looked into using an external solution quite a bit, but we really must have the fulltext criteria in the SQL, particularly as we want to sort the results by relevance and limit to only the top 200 (also limited by the other criteria).

3. Yes, if we were using an ORM, this would of course be easy. However, we're not, and we have some SQL that looks like this:

"date_field +" . $dbh->sql_interval('?', $interval)

As you can imagine, using ADD_MONTHS is not a portable solution for us.

4. In the market I work in (open source), MySQL is the clear leader. Also, would you want HTML and CSS to be described by Internet Explorer's behavior? The job of a standards body is to produce a standard that is useful and can be implemented (granted, I'm not saying ANSI did that for SQL, I'm just making a side point).

5. Modularity--the data comes from one part of the application and is going into another one. It's not just one place in the application that does this. We do use joins where we can--quite extensively in fact, since we were originally on MySQL 3 (many years ago), which didn't support subselects.

7. That's a nice attitude to take with programmers, but not with administrators or users, who might have different needs than can be imagined, and don't need to be punished when they're just trying to make something work the way they need.

-Max

LIMIT standard?

Unless it's been added fairly recently, the LIMIT clause is not ANSI standard.
The official history as far I know:
It was invented by Rasmus Lerdorf (PHP fame) for mSQL, soon implemented on MySQL (which btw has no shared code-heritage with mSQL), and then PostgreSQL. MySQL and PostgreSQL used to have slightly differing syntax but they've converged on *also* supporting a different syntax which is the same on both.
MySQL had LIMIT [skiprows,]nrows whereas PostgreSQL did LIMIT nrows[,skiprows]
This is still supported but the new syntax is LIMIT nrows [OFFSET skiprows]

Re: LIMIT standard?

Hey, you're right! You know, I actually didn't realize that. I do think LIMIT OFFSET is the most sensible way I've seen it implemented, though, of all the DBs I've used.

-Max

Two kinds of empty

Regarding point 1, do you mean it is weird that Oracle is in a minority, or weird that Oracle has not implemented the two-kinds-of-empty functionality?

It would be simple enough for them to implement it, as this is why the VARCHAR type has been reserved all these years, so I don't see a technical hurdle. I suspect that whoever decides these things at Oracle Towers feels strongly (as I do) that it is not necessary in any conceivable business modelling scenario and Oracle's welcome simplification should stand.

Re: Two kinds of empty

I think it's weird that they treat empty strings the same as NULL, because that's not true in any other programming language or database that I can think of.

The SQL Reference implies that they plan to fix it.

It is definitely important to know whether or not a user has set something or not yet, even if they've set it to the empty string. You wouldn't believe what we had to do in the DB backend to make Oracle work with Bugzilla, because of this... :-)

-Max

(Anonymous)

Re: Two kinds of empty

Why would someone want to set something to the empty string just to record the fact that they set it? I have never seen a need for this in 18 years of design and development, although as you can probably guess I've been wasting my career in the weird Oracle camp.

Post what you came up with, we could use more WTFs ;)

William

Re: Two kinds of empty

I could look through the code, but it's more of an issue of needing consistent behavior across databases.

The real problem, I suppose, that we ran into is that an empty string doesn't pass a NOT NULL constraint on a column, when it does on every other DB.

-Max

(Anonymous)

Re: Two kinds of empty

But... A NOT NULL constraint is saying this column must have a value in it, and then you're putting an empty string in it! How is that a value?

"What colour is the product?" "The product is ''."

Madness, I tell you!

Re: Two kinds of empty

An empty string is not a null in any serious programming language in existence, except apparently Oracle SQL.

-Max
To The Side

November 2010

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930    
Powered by LiveJournal.com