mysql 的delimiter
我在 EMS SQL Manager 2005 for MySQL 这个 MySQL 图形客户端下可以顺利运行。但是在 SQLyog MySQL GUI v5.02 这个客户端就会出错。最后找到原因是没有设置好 delimiter 的问题。默认情况下，delimiter “;” 用于向 MySQL 提交查询语句。在存储过程中每个 SQL 语句的结尾都有个 “;”，如果这时候，每逢 “;” 就向 MySQL 提交的话，当然会出问题了。于是更改 MySQL 的 delimiter，上面 MySQL 存储过程就编程这样子了：
mysql> delimiter // -- 改变 MySQL delimiter 为：“//” 末尾不要符号 “;”
mysql>
mysql> drop procedure if exists pr_stat_agent //
Query OK, 0 rows affected (0.00 sec)
mysql>
mysql> -- call pr_stat_agent ('2008-07-17', '2008-07-18')
mysql>
mysql> create procedure pr_stat_agent
-> (
-> pi_date_from date
-> ,pi_date_to date
-> )
-> begin
-> -- check input
-> if (pi_date_from is null) then
-> set pi_date_from = current_date();
-> end if;
->
-> if (pi_date_to is null) then
-> set pi_date_to = pi_date_from;
-> end if;
->
-> set pi_date_to = date_add(pi_date_from, interval 1 day);
->
-> -- stat
-> select agent, count(*) as cnt
-> from apache_log
-> where request_time >= pi_date_from
-> &nb
相关文档：
我经过这几天研究发现mod_perl提供的持续连接并不智能（也许是我还没有找到更
好的解决方案），如果脚本中的参数和初始化的参数不一样，在内存中会出现两个
句柄。
Apache::DBI->connect_on_init("DBI:mysql:mysql:localhost","root","root",
{
PrintError => 1,
RaiseError => 0,
AutoCommit => ......
作者：老王
MySQL5.X都已经发布好久了，但是还有很多人认为MySQL是不支持事务处理的，这不得不怪他们是孤陋寡闻的，其实，只要你的MySQL版本支持BDB或InnoDB表类型，那么你的MySQL就具有事务处理的能力。这里面，又以InnoDB表类型用的最多，虽然后来发生了诸如Oracle收购InnoDB等令MySQL不爽的事情，但那些商业上的斗争� ......
最近正在进行一个二次开发接口的项目，在开发过程中发现：我们之前使用的处理客户端和WEB之间编码兼容问题的方法是存在问题的。由于为了支持多语言，数据库表中类型为varchar的字段，他们的字符集都设置成了utf8。之前的做法是客户端将字符串的编码改成utf8编码，然后将该utf8编码的� ......
