I mentioned when grant statements take into effect in Sql Server, MySql, and Oracle here.

I found out recently that there are some implementation differences when you grant only delete permission on a table to a user. MySql and Sql Server do this the same way, whereas Oracle is different.

Suppose you have:

1. Table t1: create table t1 (c1 int);
2. User TestLogin. The only permission of this TestLogin is delete on t1.

In all 3 database platforms, TestLogin can find out what columns t1 has by default, using either

desc t1

or

sp_columns t1

In both Sql Server and MySql, the only thing you can do is:

delete from t1;

which essentially wipes out the whole table. You can do the same thing in Oracle.

However, if you do:

…

After some time here is another post concerning MySQL. It is not as if I had not had anything to do with MySQL in the meantime, but most of it was mailing back and forth with their customer support (which is really quite good) to get some issues resolved we stumbled over in our MySQL 4.1 to 5.0 migration.

Before those were fixed we could not use MySQL 5 with our application, because there were some incompatible changes we could not work around.

One of them was the unsatisfactory precision when querying DECIMALs I wrote about earlier. This is fixed in 5.0.32-enterprise and the just released 5.0.33 community edition (see Bug #23260). In fact I was just about to write about the new release policy which I find somewhat strange (enterprise and community editions with the …

After some time here is another post concerning MySQL. It is not as if I had not had anything to do with MySQL in the meantime, but most of it was mailing back and forth with their customer support (which is really quite good) to get some issues resolved we stumbled over in our MySQL 4.1 to 5.0 migration.

Before those were fixed we could not use MySQL 5 with our application, because there were some incompatible changes we could not work around.

One of them was the unsatisfactory precision when querying DECIMALs I wrote about earlier. This is fixed in 5.0.32-enterprise and the just released 5.0.33 community edition (see Bug #23260). In fact I was just about to write about the new release policy which I find somewhat strange (enterprise and community editions with the …

In both Sql Server and Oracle, permission changes to a user take into effect right away, even when said user is connected at the time you made the change.

In MySql, it is a little different, depending on how the permissions are given. If you use the GRANT statement, then it takes into effect right away. However, if you create user and give it permissions by manipulating the user table in the mysql system database directly, that is, using Sql statements, then you need to issue:

flush privileges

for those changes to be picked up.

Sql Server 2005 has a command line tool named sqlcmd. MySQL has a command line tool named mysql. Oracle has a command line tool called sqlplus. They can all be used for interactive query processing and batch scripts processing. They do similar things, albeit in different ways. They are functionally equivalent.

For Sql Server 2005, when in interactive mode of sqlcmd, use

:r c:MyFolderMyScript.sql

to read and execute a script file. You may have to type

go

afterwards, if the last line of the script file does not end with the word go.

To use sqlcmd in batch mode, that is, to run a sql script and then get out, use:

sqlcmd -i c:MyFolderMyScript.sql -S MyServerName -E

Replace -E with -U LoginName if you use Sql authentication

For MySQL, while in interactive mode of mysql, use

. c:MyFolderMyScript.sql (on Windows)

Note there should be a backward …

In Oracle and MySql, to get the column name and data type of a table, you can use:

desc MyTable

or

describe MyTable

The equivalent of desc in Sql Server is sp_columns. Therefore, run the command below will get similar results:

sp_columns MyTable

This is a reminder to anyone who works in technology, particularly open source, that the job market is healthy. If you've been waiting for the right time to start looking, that time is here.

I'm just saying this because I get a continuous stream of requests from friends, former co-workers, open source community associates, and random people who read here. Things like "Mike, we desperately need a MySQL DBA. Do you know anyone?" or "Do you know anyone who is available to do some PHP/Perl work." My unscientific sense is that companies are paying more because good open source folks are in demand.

Rather than posting every individual job that comes along I'm just going to say it once in general...look around. You'll find them. These companies are out there actively looking, they aren't the very special, hidden, must-be-part-of-a-secret-society jobs. You should be able to find them with a little poking around.

Just a …

I've been needing this for some time; the ability to search for apt-get packages on Ubuntu when I don't know the name of the package. Turns out there's a corresponding utility for doing this:

shell> apt-cache search <search string>


You'll want to be sure your repository is up to date with apt-get update. Today I need DBI to get Perl connected to MySQL, but can't figure out what the apt-get package name is (I tried "DBI", "perl-DBI", "DBI-perl"). A search immediately gives me what I need:

shell> apt-cache search dbi
libdbd-mysql-perl - A Perl5 database interface to the MySQL database
libdbi-perl - Perl5 database interface by Tim Bunce
libxml-sax-perl - Perl module for using and building Perl SAX2 XML processors


And find that apt-get install libdbi-perl gets me right back on the road.

Ubuntu (in …

Reading about Peter Zaitsev's feature idea about Finding columns which a query needs to access - which I would really like to see implemented - reminded me of a bug report I filed in 2004 and which bit me again only a few days ago. You can find it under Bug #7074 in the MySQL bug tracking tool. Although it is filed as a feature request, I think one should be aware of this, as it may cause problems in your applications (it did in ours).

Basically it is about explicitly specifying which columns you need in a result set, instead of just using SELECT *. This is generally a good idea, however if the table contains BLOB columns, it becomes even more important, as …

Reading about Peter Zaitsev's feature idea about Finding columns which a query needs to access - which I would really like to see implemented - reminded me of a bug report I filed in 2004 and which bit me again only a few days ago. You can find it under Bug #7074 in the MySQL bug tracking tool. Although it is filed as a feature request, I think one should be aware of this, as it may cause problems in your applications (it did in ours).

Basically it is about explicitly specifying which columns you need in a result set, instead of just using SELECT *. This is generally a good idea, however if the table contains BLOB columns, it becomes even more important, as …