Re: [AOLSERVER] Retrieving oid from INSERT
Most of the web world runs on MySQL and does ok - just like CDBaby who You can't possibly liken Sybase to MySQL! I know that they are not even in the same league technically, but they do show disturbingly similar philosophies - like making NULL = NULL by default because many clients with poorly trained developers asked for it. with Sybase because you end up needing more lines of code. That is a purely gut feel however. I don't see why, what do you think Oracle offers that Sybase doesn't and gives it an advantage? 99% of applications I see are nothing more than straight SQL jobs. And even when stored procs are involved, I find T-SQL a much nicer and language than PL/SQL and uses less code to achieve the same thing. I was really commenting on the sql rather than stored procs. Simple things like trying to format a date (that's not one of the fixed and oddly numbered formats) can be quite trying in Sybase. I do find the T-SQL syntax quite cumbersome too, but I suspect that is more personal preference than anything else. Enterprise features like replication is one of the things that lets [Postgres] down. While miles ahead of the other free database, backup isn't great either. The version 8 option of stop checkpoints, copy data files and the automatic archiving of log files is nice, but they need to go one more step to the equivalent of Sybase's dump database and dump tran commands. Agreed. Backup has always been weak although it's a lot better than it was. Same with replication although I am very interested to try out Slony and also the replication solution from commandprompt.com. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
That's great - I'm a bit of a Sybase newby and this tip makes life a lot easier. Given that this is so easy and reasonable I don't understand why so many Sybase developers employ other unreliable methods to emulate triggers. On 4/5/06, Bas Scheffers [EMAIL PROTECTED] wrote: select @@identity for the last identity value assigned in the current session. This is acros all tables with id columns, so if you are inserting multiple in one transaction and need all of them, be sure to assign them to another variable after each insert. Cheers, Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
Mark Aufflick said: do show disturbingly similar philosophies - like making NULL = NULL by default because many clients with poorly trained developers asked for I recon that's the only one! (and I still don't see why this is such a bad thing) My problem with MySQL isn't this simplification, it's the inconsistencies. (apart from other known issues) Sybase is very consistent in what it does, even if you find it's not the way _you_ would like it to do things. things like trying to format a date (that's not one of the fixed and oddly numbered formats) can be quite trying in Sybase. Absolutely right; it's stupid the default output isn't ANSI format. All sybase projects I have been on in the past few years were Java, so I just got a Date object back just like with any other database and formatting wasn't an issue. That said: I don't tend to use any formatting features of the database in my web apps on AOLserver. (or Vignette, which also uses Tcl) Instead, I take the default format and simply create a date_format Tcl procedure I pass everything through. If needed, I first use a regexp (or split/lindex) to put the date from the db into something clock scan can take in and then format it using the clock format command. I don't even see this as a workaround for the database's limitations; it makes perfect sense to have one date format proc to be used throughout the website as dates never have more than one or two formats on any given site. For Sybase I would simply select all dates as convert(varchar(20), date_col, 23) to get back the 2005-12-23T15:33:32 format. clock scan parses this fine if you just take out the T. (it parses it with the T too, but gets the time wrong and thinks it is 7 hours earlier for me!) Sybase does also take the ANSI 2005-12-23 15:33:32 format as input, so that is one less thing to worry about. Another shortcomming of dates in Sybase is a complete lack of timezones. If needed, I get around this by storing everything as UTC. Java's PreparedStatement makes this quite easy - as long as you use jconn3 as version 2 didn't due to a bug - you can use the -gmt 1 switch in clock scan/format for Tcl. But that does make using getdate() as defaults impossible. I do find the T-SQL syntax quite cumbersome too, but I suspect that is more personal preference than anything else. It could very well be what you grew up on; I used T-SQL before anything else and just hate PL/SQL! Cheers, Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 2006.04.06, Mark Aufflick [EMAIL PROTECTED] wrote: That's great - I'm a bit of a Sybase newby and this tip makes life a lot easier. Given that this is so easy and reasonable I don't understand why so many Sybase developers employ other unreliable methods to emulate triggers. For the exact same reason you almost did: new developers don't know any better, but most of them don't bother to ask anyone. Instead, they go ahead and implement some crazy brokenness because they have to just make it work ... I find most crap code ends up written this way. On 2006.04.06, Mark Aufflick [EMAIL PROTECTED] wrote: Most of the web world runs on MySQL and does ok - just like CDBaby who You can't possibly liken Sybase to MySQL! I know that they are not even in the same league technically, but they do show disturbingly similar philosophies - like making NULL = NULL by default because many clients with poorly trained developers asked for it. You're right; MySQL is orders of magnitude better than Sybase. I'm dead serious. (I've been doing work in Sybase lately and I have to tell you: T-SQL is so damn awful, it would probably be better off without any stored procedure capability than to have it.) And, where are you getting your misinformation about MySQL about? Here's a test I did just now (MySQL 4.1.11): mysql create table dossy (x int, y int); Query OK, 0 rows affected (0.07 sec) mysql insert into dossy (x, y) values (1, 1), (2, 2), (3, NULL), (4, NULL); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql select * from dossy where y = NULL; Empty set (0.00 sec) mysql select * from dossy where y IS NULL; +--+--+ | x| y| +--+--+ |3 | NULL | |4 | NULL | +--+--+ 2 rows in set (0.00 sec) MySQL is far more standards-compliant than Sybase. Did you know that Sybase silently promotes an empty string to a string of 1 character? You can't actually store an empty string in a Sybase database. That is absolutely ridiculous. I'd expect that kind of behavior from some college-level pidgin databases class project, not from something people are expected to pay real money for. Sybase's TEXT/IMAGE support is ridiculous. You can't create stored procedures which take parameters that are typed TEXT or IMAGE? You have to jump through ridculous hoops with VARBINARY pointers and READTEXT/WRITETEXT? I suppose Oracle's not much better in this regard, with all their DBMS_LOB package shenanigans. MySQL claims any data type can be used as a stored procedure parameter -- I'll have to test to see how it handles BLOB and CLOB types. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
Dossy Shiobara said:
You're right; MySQL is orders of magnitude better than Sybase. I'm dead
Yeah, when it doesn't blow up in weird and wonderul ways... And you don't
mind not being able to do online backups And if you think '-00-00'
or '2006-02-30' is a date... (oh no, just tested mysql 5 silently turns
the latter into '-00-00'!) And expect 2 ints added together to form a
value more than 32 bits to be silently cast to a long... The list goes on
and on.
T-SQL is so damn awful, it would probably be better off without any
stored procedure capability than to have it.)
Some people feel the same about PL/SQL... Or that basterdazation of PL/SQL
used in Postgres. T-SQL isn't perfect, but it has always gotten the job
done for me quite easily and efficiently. Different strokes for differen
folks.
Did you know that Sybase silently promotes an empty string to a string
of 1 character?
Most database can't, they just silently make it NULL. Not sure which is
worse... In fact, MySQL does *very* weird things with empty and semi-empty
strings:
mysql select concat('',foo,'') from test2 where foo = ' ';
+-+
| concat('',foo,'') |
+-+
| |
| |
+-+
2 rows in set (0.00 sec)
Yes, those are 3 spaces in the where clause and MySQL returns rows with
both empty strings and one space!
Oh, and did you notice how it trims the values of char() columns?
mysql create table test3 (foo char(10));
Query OK, 0 rows affected (0.02 sec)
mysql insert into test3 values ('a ');
Query OK, 1 row affected (0.00 sec)
mysql select concat('',foo,'') from test3;
+-+
| concat('',foo,'') |
+-+
| a |
+-+
1 row in set (0.00 sec)
Just to make sure I have a recent version:
mysql \s
--
mysql Ver 14.12 Distrib 5.0.18, for redhat-linux-gnu (i386)
Sybase's TEXT/IMAGE support is ridiculous. You can't create stored
procedures which take parameters that are typed TEXT or IMAGE? You have
That is silly, yes. But like you say, it's not better in any of the other
commercial databases.
to jump through ridculous hoops with VARBINARY pointers and
READTEXT/WRITETEXT? I suppose Oracle's not much better in this regard,
A tiny hoop, really. Plus it seems to be a problem with the C driver more
than anything else. In JDBC, you can send as much data as you like for an
insert or update of a TEXT/IMAGE column.
can be used as a stored procedure parameter -- I'll have to test to see
how it handles BLOB and CLOB types.
Does MySQL still use/support actual LOBs? (as in data stored elsewhere
from the row) I thought everything was stored in-line and clob/blob was
just a synonym for varchar(2B), just like in Postgres?
I don't mind anyone who prefers Oracle over Sybase. But to say MySQL is
much better and more standards compliant just because you don't like a few
things in Sybase (which, as it turns out MySQL isn't very good at either)
is, well, a little strange.
Just my $0.02...
Bas.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 2006.04.06, Bas Scheffers [EMAIL PROTECTED] wrote: Dossy Shiobara said: You're right; MySQL is orders of magnitude better than Sybase. I'm dead Yeah, when it doesn't blow up in weird and wonderul ways... [...] I'll bet a nickel it's user error (whether that user is a developer or the DBA). [...] And you don't mind not being able to do online backups [...] Oh man, who is feeding you this pack of lies? I mean, MySQL has been able to do hot online backups since May 2002! Well, you've been able to do them for MyISAM table types much earlier than that, but the InnoDB Hot Backup product reached version 1.00 in May 2002. [...] And if you think '-00-00' or '2006-02-30' is a date... (oh no, just tested mysql 5 silently turns the latter into '-00-00'!) [...] There's a very good reason for this, AND if you find it objectionable, you can even turn it off: http://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.html MySQL also allows you to store '-00-00' as a dummy date (if you are not using the NO_ZERO_DATE SQL mode). This is in some cases is more convenient (and uses less space in data and index) than using NULL values. [...] And expect 2 ints added together to form a value more than 32 bits to be silently cast to a long... The list goes on and on. My understanding is that the data type determines the number of bits/bytes used at the storage layer, but all mathematics and aggregate functions should operate at the highest precision and largest word size. MySQL documents this: http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html MySQL supports arithmetic with both signed and unsigned 64-bit values. If you are using numeric operators (such as +) and one of the operands is an unsigned integer, the result is unsigned. You can override this by using the SIGNED and UNSIGNED cast operators to cast the operation to a signed or unsigned 64-bit integer, respectively. If you want to truncate a value to 32-bits, your database should offer you a way to do so. MySQL does, albeit a bit awkward: mysql select (pow(2, 32) + 8675309) 32 32; ++ | (pow(2, 32) + 8675309) 32 32 | ++ |8675309 | ++ T-SQL is so damn awful, it would probably be better off without any stored procedure capability than to have it.) Some people feel the same about PL/SQL... Or that basterdazation of PL/SQL used in Postgres. T-SQL isn't perfect, but it has always gotten the job done for me quite easily and efficiently. Different strokes for differen folks. I've done plenty of PL/SQL in Oracle from 7.3 through 9i, and T-SQL in Sybase 11.5 through 12.5 -- both modern versions -- and given the choice, I'd choose Oracle and PL/SQL over Sybase and T-SQL. That's my personal preference, naturally, but one based on first-hand experience with both. Did you know that Sybase silently promotes an empty string to a string of 1 character? Most database can't, they just silently make it NULL. Not sure which is worse... Not being able to store a string of length 0 is worse. In fact, MySQL does *very* weird things with empty and semi-empty strings: [...] Yes, those are 3 spaces in the where clause and MySQL returns rows with both empty strings and one space! The row where you got one space back: I'd like to see how you inserted the data. In general, this isn't weird at all, because ... Oh, and did you notice how it trims the values of char() columns? Absolutely. MySQL trims trailing whitespace on CHAR values: http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html Note: Trailing spaces are removed when CHAR values are retrieved. ... Note: Before 5.0.3, trailing spaces were removed when VARCHAR values were stored, which differs from the standard SQL specification. Does MySQL still use/support actual LOBs? (as in data stored elsewhere from the row) I thought everything was stored in-line and clob/blob was just a synonym for varchar(2B), just like in Postgres? http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html [...] InnoDB stores the first 768 bytes of a VARCHAR, BLOB, or TEXT column in the row, and the rest into separate pages. If you want to use MyISAM and store the LOB data in a separate place, you could manually do something similar to what Postgres does: store the LOBs in the filesystem and generate a unique ID and just store that in the row, or store the LOBs in a separate table and again, just store the unique ID in the row. I don't mind anyone who prefers Oracle over Sybase. But to say MySQL is much better and more standards compliant just because you don't like a few things in Sybase (which, as it turns out MySQL isn't very good at either) is, well, a little strange. The difference? If I *had* to, I
Re: [AOLSERVER] Retrieving oid from INSERT
It sounds like you guys are comparing rotten oranges and rotten apples.
tom jackson
On Thursday 06 April 2006 05:37, Bas Scheffers wrote:
Dossy Shiobara said:
You're right; MySQL is orders of magnitude better than Sybase. I'm dead
Yeah, when it doesn't blow up in weird and wonderul ways... And you don't
mind not being able to do online backups And if you think '-00-00'
or '2006-02-30' is a date... (oh no, just tested mysql 5 silently turns
the latter into '-00-00'!) And expect 2 ints added together to form a
value more than 32 bits to be silently cast to a long... The list goes on
and on.
T-SQL is so damn awful, it would probably be better off without any
stored procedure capability than to have it.)
Some people feel the same about PL/SQL... Or that basterdazation of PL/SQL
used in Postgres. T-SQL isn't perfect, but it has always gotten the job
done for me quite easily and efficiently. Different strokes for differen
folks.
Did you know that Sybase silently promotes an empty string to a string
of 1 character?
Most database can't, they just silently make it NULL. Not sure which is
worse... In fact, MySQL does *very* weird things with empty and semi-empty
strings:
mysql select concat('',foo,'') from test2 where foo = ' ';
+-+
| concat('',foo,'') |
+-+
| |
| |
+-+
2 rows in set (0.00 sec)
Yes, those are 3 spaces in the where clause and MySQL returns rows with
both empty strings and one space!
Oh, and did you notice how it trims the values of char() columns?
mysql create table test3 (foo char(10));
Query OK, 0 rows affected (0.02 sec)
mysql insert into test3 values ('a ');
Query OK, 1 row affected (0.00 sec)
mysql select concat('',foo,'') from test3;
+-+
| concat('',foo,'') |
+-+
| a |
+-+
1 row in set (0.00 sec)
Just to make sure I have a recent version:
mysql \s
--
mysql Ver 14.12 Distrib 5.0.18, for redhat-linux-gnu (i386)
Sybase's TEXT/IMAGE support is ridiculous. You can't create stored
procedures which take parameters that are typed TEXT or IMAGE? You have
That is silly, yes. But like you say, it's not better in any of the other
commercial databases.
to jump through ridculous hoops with VARBINARY pointers and
READTEXT/WRITETEXT? I suppose Oracle's not much better in this regard,
A tiny hoop, really. Plus it seems to be a problem with the C driver more
than anything else. In JDBC, you can send as much data as you like for an
insert or update of a TEXT/IMAGE column.
can be used as a stored procedure parameter -- I'll have to test to see
how it handles BLOB and CLOB types.
Does MySQL still use/support actual LOBs? (as in data stored elsewhere
from the row) I thought everything was stored in-line and clob/blob was
just a synonym for varchar(2B), just like in Postgres?
I don't mind anyone who prefers Oracle over Sybase. But to say MySQL is
much better and more standards compliant just because you don't like a few
things in Sybase (which, as it turns out MySQL isn't very good at either)
is, well, a little strange.
Just my $0.02...
Bas.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the
email message. You can leave the Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
Tom Jackson said: It sounds like you guys are comparing rotten oranges and rotten apples. Are there any apples that aren't considered rotten by someone, somewhere? Like I said before, every RDBMS has it's issues... ...MySQL just takes them to a whole new level and gets even otherwise sensible people like Dossy (sorry to be speaking in the 3rd person here) describing bugs as features. Oh well. Cheers, Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
Dossy Shiobara said:
Oh man, who is feeding you this pack of lies? I mean, MySQL has been
able to do hot online backups since May 2002! Well, you've been able to
How? All I can find is this mysqldump and mysqlhotcopy, which lock
tables while they are being dumped. Hardly online backup if you ask me.
do them for MyISAM table types much earlier than that, but the InnoDB
Hot Backup product reached version 1.00 in May 2002.
That is true, in fact I knew about it. Usualy when the pgsql/mysql debate
comes up I use this to point out another reason why MySQL is free in
beer nor speech. But compared to Sybase of course this argument is lost.
(unless you run a small(ish) database on (free, as in beer) Sybase
Express, of course!)
There's a very good reason for this, AND if you find it objectionable,
you can even turn it off:
I found the page it is documented on, but I don't find This is in some
cases is more convenient (and uses less space in data and index) than
using NULL values. good enough reason. Besides, if you turn it off many
3rd party apps will fail as they rely on the functionality being there.
My understanding is that the data type determines the number of
bits/bytes used at the storage layer, but all mathematics and aggregate
functions should operate at the highest precision and largest word size.
That doesn't fly when you expect a .NET or JDBC .getInt() to do just that.
So unless you specifically ask for it to be casted up, I believe the
database should throw the error, not your client program. Just because it
is documented, doesn't make it right!
The row where you got one space back: I'd like to see how you inserted
the data. In general, this isn't weird at all, because ...
insert into test4 values (null), (''), ('a '), (' ');
Actually, I stand corrected on that one, Sybase is a messed up in this
case as MySQL. Postgres gets it right, though.
Absolutely. MySQL trims trailing whitespace on CHAR values:
Doesn't that go against standards? Then what is the point of having char
fields to begin with?
The difference? If I *had* to, I could extend MySQL to do exactly what
I need. (Beware: Tcl as a supported UDF language for MySQL stored
procs! Muwahaha.)
Why waste your time, Postgres already has that! :) (and loads of other
features MySQL doesn't have, plus it is truly Free and as ANSI compliant
as they get)
Cheers,
Bas.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 2006.04.06, Bas Scheffers [EMAIL PROTECTED] wrote: The difference? If I *had* to, I could extend MySQL to do exactly what I need. (Beware: Tcl as a supported UDF language for MySQL stored procs! Muwahaha.) Why waste your time, Postgres already has that! :) (and loads of other features MySQL doesn't have, plus it is truly Free and as ANSI compliant as they get) Can you embed Postgres? Before I got turned on to SQLite, MySQL served as a great embedded database inside the real applications. Can Postgres do the same? (Moot point, really, since I now just use SQLite for this, but it's good trivia to know, anyway.) PostgreSQL 8.0's support of Win32 will help things, too. As much as people criticize MySQL's replication and clustering, where's Postgres's? I don't see any mention of it in Postgres 8.1 docs: http://www.postgresql.org/docs/8.1/interactive/index.html The docs also don't mention any GIS support. I agree, Postgres is a fine database. I would be happy using it if I were working in an environment that already had it deployed. But, I don't see a compelling reason to try and convert a shop over to Postgres. Just the same, I don't feel a big need to migrate folks onto MySQL, either. ... except, if they're using Sybase. Then, I'd advocate migrating onto any other RDBMS, just because having to work in Sybase would be more effort. Seriously. 16K max page size? Not being able to create stored procedures with TEXT or IMAGE parameters? How do you build a content management system on top of Sybase? A whole lot of dynamic SQL in the application? I guess ... in which case, if you're not leveraging stored procedures, why not just use MySQL or Postgres? Sigh. I'm glad you like Sybase. Someone has to; better you than me, for sure. :-) -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 6 Apr 2006, at 17:42, Dossy Shiobara wrote: Can you embed Postgres? Before I got turned on to SQLite, MySQL served I don't see that as a downside, it's not what I use it for. Like you say, there's SQLite for that. Try embedding MySQL into a non-GPL project and see how free it is then! :( PostgreSQL 8.0's support of Win32 will help things, too. For some, I guess. I wouldn't want to run a production app on a Windows box anyway! But yeah, it's there and supposedly even simpler to get going than MySQL is on Windows! (though I have never tried MySQL on windows, but Postgres's installer is very good) As much as people criticize MySQL's replication and clustering, where's Postgres's? I don't see any mention of it in Postgres 8.1 docs: Nope, just 3rd party products. Supposedly good, but I have never tried them. The docs also don't mention any GIS support. The comunity does, though. PostGIS is quite mature. And I am making good use of the point datatype and it's related operators to search for stuff in a radius around a postcode, very efficient. don't see a compelling reason to try and convert a shop over to Postgres. Just the same, I don't feel a big need to migrate folks onto Maybe not with MySQL 5 and InnoDB anymore. I would run a mile from previous versions, though. And as those didn't have stored procs, porting would be easy. ... except, if they're using Sybase. Then, I'd advocate migrating onto any other RDBMS, just because having to work in Sybase would be more What did the kind folks at Sybase do to you as a child! :) effort. Seriously. 16K max page size? Not being able to create stored How is that a bad limit? The 2K pages and varchar(255) were terrible, but 16K isn't a problem. Yes, you still can't do 2GB varchars, but neither can Oracle or any of the big 4 databases. (though not sure about DB2) You have to go to a free one for that. procedures with TEXT or IMAGE parameters? How do you build a content management system on top of Sybase? A whole lot of dynamic SQL in the Personally, I have never in any CMS system had more than 16K in any CLOB. 16K is a freakin' big amount of text for a website! In any case it seems to be better than Oracle's 4000. I'm glad you like Sybase. Someone has to; better you than me, for sure. :-) Hehe, ditto, and also for your love of Oracle! :) Isn't AOL still a big Sybase shop anyways? Cheers, Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 2006.04.06, Bas Scheffers [EMAIL PROTECTED] wrote: As much as people criticize MySQL's replication and clustering, where's Postgres's? I don't see any mention of it in Postgres 8.1 docs: http://www.postgresql.org/docs/8.1/interactive/index.html That's because replication isn't part of basic PG support. You can choose a couple of options, though: PGCluster - Multi-master no delay synchronus replication for load sharing or HA. Large objects are now supported. Slony-I - Master to multi-slave cascading and almost-failover. The docs also don't mention any GIS support. PostgreSQL has had operators and index support for polygons and the like forever. Some of the earliest users of PG with large databases were in the GIS realm. Just the same, I don't feel a big need to migrate folks onto MySQL, either. The people who wrote MySQL have the ethical standards of the George W. Bush administration. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 6 Apr 2006, at 19:13, dhogaza@PACIFIER.COM wrote: The people who wrote MySQL have the ethical standards of the George W. Bush administration. What, it's made by the same folks as those behind JBoss!? ;-) Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 4/6/06, Dossy Shiobara [EMAIL PROTECTED] wrote: Did you know that Sybase silently promotes an empty string to a string of 1 character? You can't actually store an empty string in a Sybase database. That is absolutely ridiculous. I'd expect that kind of behavior from some college-level pidgin databases class project, not from something people are expected to pay real money for. Although that's not a dissimilar problem to the NULL as empty string issue in the Oracle C libraries (which really really bites). -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 4/6/06, Bas Scheffers [EMAIL PROTECTED] wrote: Mark Aufflick said: do show disturbingly similar philosophies - like making NULL = NULL by default because many clients with poorly trained developers asked for I recon that's the only one! (and I still don't see why this is such a bad thing) My problem with MySQL isn't this simplification, it's the inconsistencies. (apart from other known issues) Sybase is very consistent in what it does, even if you find it's not the way _you_ would like it to do things. I feel a good old fashioned usenet style flame war coming on =) In Sybase, NULL matches NULL in a search clause (by default - as established), but NULL will never match anything (not even itself) in a join ( http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/13175 ). That doesn't sound very consistent! I do find the T-SQL syntax quite cumbersome too, but I suspect that is more personal preference than anything else. It could very well be what you grew up on; I used T-SQL before anything else and just hate PL/SQL! You are probably correct. (Although I grew up on Applesoft basic and I don't like VB!) Should we call a truce? ;) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Retrieving oid from INSERT
On 4/7/06, Mark Aufflick [EMAIL PROTECTED] wrote: On 4/6/06, Dossy Shiobara [EMAIL PROTECTED] wrote: Did you know that Sybase silently promotes an empty string to a string of 1 character? You can't actually store an empty string in a Sybase database. That is absolutely ridiculous. I'd expect that kind of behavior from some college-level pidgin databases class project, not from something people are expected to pay real money for. Although that's not a dissimilar problem to the NULL as empty string issue in the Oracle C libraries (which really really bites). And it also reminds me - Sybase silently truncates strings if you try to insert a string that is longer than the char/varchar field. If that's not mysql-esque I don't know what is. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
