[Care2002-developers] ADOdb Issues
The current ADOdb library is v5.11 on Care2x SVN trunk.
It was v5.10 till about 2 to 3 weeks ago.
When a record is inserted into a table, we use ADOdb's method $db-Insert_ID()
to get us the last inserted ID where $db is the ADOdb connection object.
The definition of the said method is in classes/adodb/adodb.inc.php files and
is used within ADOdb in two files:-
adodb-csvlib.inc.php - Line 44: $sql .= ','.$conn-Insert_ID();
adodb-perf.inc.php (for logging) - Line 107:$conn-lastInsID =
@$conn-Insert_ID();
The specific MySQL driver we are using here is
/calsses/adodb/drivers/adodb-mysq.inc.php
The said driver has a class mysql that extends the base cass ADOConnection
It has the class variable: var $hasInsertID = true;
It also has a class method: _insertid()
This method returns the last insert id and may possibly be for private use.
The default class variables values in the base class ADOConnection are:
var $lastInsID = false;
var $hasInsertID = false; /// supports autoincrement ID?
The latter is however overridden by a re-assignment in the mysql class.
The class method ADOConnection::Insert_ID() is:
function Insert_ID($table='',$column='')
{
if ($this-_logsql $this-lastInsID) return $this-lastInsID;
if ($this-hasInsertID) return $this-_insertid($table,$column);
if ($this-debug) {
ADOConnection::outp( 'pInsert_ID error/p');
adodb_backtrace();
}
return false;
}
From the above it is clear that for the _insertid() to work, it should have
the table name and column name provided otherwise we have to check out what
defaults it will take.
Regards,
Ap.Muthu
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
hi muthu,
if you read the comments of fucntion Insert_ID() in file
adodb.in.php
it writes
/**
* @param $table string name of the table, not needed by all
databases (eg. mysql), default ''
* @param $column string name of the column, not needed by all
databases (eg. mysql), default ''
* @return the last inserted ID. Not all databases support this.
*/
gj.
On 2010-09-29 11:02.PD, Ap.Muthu wrote:
The current ADOdb library is v5.11 on Care2x SVN trunk.
It was v5.10 till about 2 to 3 weeks ago.
When a record is inserted into a table, we use ADOdb's method
$db-Insert_ID() to get us the last inserted ID where $db is the ADOdb
connection object.
The definition of the said method is in classes/adodb/adodb.inc.php files and
is used within ADOdb in two files:-
adodb-csvlib.inc.php - Line 44: $sql .= ','.$conn-Insert_ID();
adodb-perf.inc.php (for logging) - Line 107:$conn-lastInsID =
@$conn-Insert_ID();
The specific MySQL driver we are using here is
/calsses/adodb/drivers/adodb-mysq.inc.php
The said driver has a class mysql that extends the base cass ADOConnection
It has the class variable: var $hasInsertID = true;
It also has a class method: _insertid()
This method returns the last insert id and may possibly be for private use.
The default class variables values in the base class ADOConnection are:
var $lastInsID = false;
var $hasInsertID = false; /// supports autoincrement ID?
The latter is however overridden by a re-assignment in the mysql class.
The class method ADOConnection::Insert_ID() is:
function Insert_ID($table='',$column='')
{
if ($this-_logsql $this-lastInsID) return $this-lastInsID;
if ($this-hasInsertID) return $this-_insertid($table,$column);
if ($this-debug) {
ADOConnection::outp( 'pInsert_ID error/p');
adodb_backtrace();
}
return false;
}
From the above it is clear that for the _insertid() to work, it should have
the table name and column name provided otherwise we have to check out what
defaults it will take.
Regards,
Ap.Muthu
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not to
try with latest adbodb layer if that strange behaviour could be covered
with it?
Robert
Am Mittwoch, den 29.09.2010, 11:20 +0200 schrieb Gjergj Sheldija:
hi muthu,
if you read the comments of fucntion Insert_ID() in file
adodb.in.php
it writes
/**
* @param $table string name of the table, not needed by all
databases (eg. mysql), default ''
* @param $column string name of the column, not needed by all
databases (eg. mysql), default ''
* @return the last inserted ID. Not all databases support this.
*/
gj.
On 2010-09-29 11:02.PD, Ap.Muthu wrote:
The current ADOdb library is v5.11 on Care2x SVN trunk.
It was v5.10 till about 2 to 3 weeks ago.
When a record is inserted into a table, we use ADOdb's method
$db-Insert_ID() to get us the last inserted ID where $db is the ADOdb
connection object.
The definition of the said method is in classes/adodb/adodb.inc.php files
and is used within ADOdb in two files:-
adodb-csvlib.inc.php - Line 44: $sql .= ','.$conn-Insert_ID();
adodb-perf.inc.php (for logging) - Line 107:$conn-lastInsID =
@$conn-Insert_ID();
The specific MySQL driver we are using here is
/calsses/adodb/drivers/adodb-mysq.inc.php
The said driver has a class mysql that extends the base cass
ADOConnection
It has the class variable: var $hasInsertID = true;
It also has a class method: _insertid()
This method returns the last insert id and may possibly be for private use.
The default class variables values in the base class ADOConnection are:
var $lastInsID = false;
var $hasInsertID = false; /// supports autoincrement ID?
The latter is however overridden by a re-assignment in the mysql class.
The class method ADOConnection::Insert_ID() is:
function Insert_ID($table='',$column='')
{
if ($this-_logsql $this-lastInsID) return $this-lastInsID;
if ($this-hasInsertID) return $this-_insertid($table,$column);
if ($this-debug) {
ADOConnection::outp( 'pInsert_ID error/p');
adodb_backtrace();
}
return false;
}
From the above it is clear that for the _insertid() to work, it should
have the table name and column name provided otherwise we have to check
out what defaults it will take.
Regards,
Ap.Muthu
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
--
--
CARE2X - free Integ Hospital Info System
https://sourceforge.net/projects/care2002/
http://www.care2x.org
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
Thanks GJ for the MySQL defaults.
In v5.11 - adodb.inc.php:
function RowLock($table,$where,$col='1 as adodbignore')
was in v5.10
function RowLock($table,$where,$col='1 as ignore')
Now analysing the differences between v5.11 and v5.10, we find that a new
class variable called
var $bulkBind = false; // enable 2D Execute array
has been newly introduced in v5.11 of adodb.inc.php in the class
ADOConnection
This variable is used as an additional check in v5.11 at line 956:
$array_2d = $this-bulkBind is_array($element0)
!is_object(reset($element0));
The Last Insert ID is essentially an SQL statement in ADODB and hence the
above may something to do with it.
Regards,
Ap.Muthu
hi muthu,
if you read the comments of fucntion Insert_ID() in file
adodb.in.php
it writes
/**
* @param $table string name of the table, not needed by all
databases (eg. mysql), default ''
* @param $column string name of the column, not needed by all
databases (eg. mysql), default ''
* @return the last inserted ID. Not all databases support this.
*/
gj.
On 2010-09-29 11:02.PD, Ap.Muthu wrote:
The current ADOdb library is v5.11 on Care2x SVN trunk.
It was v5.10 till about 2 to 3 weeks ago.
When a record is inserted into a table, we use ADOdb's method
$db-Insert_ID() to get us the last inserted ID where $db is the ADOdb
connection object.
The definition of the said method is in classes/adodb/adodb.inc.php files
and is used within ADOdb in two files:-
adodb-csvlib.inc.php - Line 44: $sql .= ','.$conn-Insert_ID();
adodb-perf.inc.php (for logging) - Line 107:$conn-lastInsID =
@$conn-Insert_ID();
The specific MySQL driver we are using here is
/calsses/adodb/drivers/adodb-mysq.inc.php
The said driver has a class mysql that extends the base cass
ADOConnection
It has the class variable: var $hasInsertID = true;
It also has a class method: _insertid()
This method returns the last insert id and may possibly be for private
use.
The default class variables values in the base class ADOConnection are:
var $lastInsID = false;
var $hasInsertID = false; /// supports autoincrement ID?
The latter is however overridden by a re-assignment in the mysql class.
The class method ADOConnection::Insert_ID() is:
function Insert_ID($table='',$column='')
{
if ($this-_logsql $this-lastInsID) return $this-lastInsID;
if ($this-hasInsertID) return $this-_insertid($table,$column);
if ($this-debug) {
ADOConnection::outp( 'pInsert_ID error/p');
adodb_backtrace();
}
return false;
}
From the above it is clear that for the _insertid() to work, it should
have the table name and column name provided otherwise we have to check
out what defaults it will take.
Regards,
Ap.Muthu
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
Hi Robert,
Try to make the table without any records and the default AUTO_INCREMENT to
start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted).
Then make an insert with a pid = 1000 in the insert statement and check
the Last insert ID():
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
Regards,
Ap.Muthu
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not to
try with latest adbodb layer if that strange behaviour could be covered
with it?
Robert
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
Sorry, I do not get the point. When you do that then you will have the
query result of LAST_INSERT_ID() 1001
There is on table definition an autoincrement and you give in your
insert statement an fixed value to it? The result is always strange
(guess it will be 1001 instead of 1000 - not tested so
far...why?)
Do do you want to make me busy? :-)
Robert
Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu:
Hi Robert,
Try to make the table without any records and the default AUTO_INCREMENT to
start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted).
Then make an insert with a pid = 1000 in the insert statement and check
the Last insert ID():
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
Regards,
Ap.Muthu
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not to
try with latest adbodb layer if that strange behaviour could be covered
with it?
Robert
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
--
--
CARE2X - free Integ Hospital Info System
https://sourceforge.net/projects/care2002/
http://www.care2x.org
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
Hi,
I just tested it out here as well:
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.02 sec)
mysql INSERT INTO `care_person` (`pid`, `name`) VALUES (1000,
'Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
So we have a different behaviour under windows and linux. But I would no
like to have such autoincrement decrements (AI - 1) in the code
(readability, maintainability, reliability.. in case that this will be
fixed by mysql later it would be a real ugly workaround what might bring
working HIS outside in real trouble by updating mysql).
Before doing that, I would suggest to create an dummy record in
care_person. (if adodb does not support here any suggestion on that
issue)
Robert
Am Mittwoch, den 29.09.2010, 15:49 +0530 schrieb Ap.Muthu:
Hi Robert,
I have tested it to be a MySQL issue and not a ADOdb issue.
On execution of the said statements, I get the Last Insert ID as 0.
So our care2x code seems to be inserting this kind of insert sql.
Possibly if we altered the AUTO_INCREMENT value on the table to be
(1000 - 1)
and then performed a normal SQL insert without the
AUTO_INCREMENT field pid, we might be able avoid such issues.
CREATE TABLE `care_person` (
`pid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
The attached pre-test image is the situation just after table creation.
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
After execution of the said 3 sqls, the backup schema of the table is:
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL auto_increment,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
The attached mess image is taken after all the above SQLs have been
executed.
Regards,
Ap.Muthu
Sorry, I do not get the point. When you do that then you will have the
query result of LAST_INSERT_ID() 1001
There is on table definition an autoincrement and you give in your
insert statement an fixed value to it? The result is always strange
(guess it will be 1001 instead of 1000 - not tested so
far...why?)
Do do you want to make me busy? :-)
Robert
Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu:
Hi Robert,
Try to make the table without any records and the default AUTO_INCREMENT
to
start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted).
Then make an insert with a pid = 1000 in the insert statement and
check
the Last insert ID():
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
Regards,
Ap.Muthu
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not to
try with latest adbodb layer if that strange behaviour could be covered
with it?
Robert
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
--
--
CARE2X - free Integ Hospital Info System
https://sourceforge.net/projects/care2002/
http://www.care2x.org
Re: [Care2002-developers] ADOdb Issues
If the following is executed before attempting to create a new first person
then the last insert id of adodb will work:
ALTER TABLE `care_person` AUTO_INCREMENT=999;
Hi Robert,
I have tested it to be a MySQL issue and not a ADOdb issue.
On execution of the said statements, I get the Last Insert ID as 0.
So our care2x code seems to be inserting this kind of insert sql.
Possibly if we altered the AUTO_INCREMENT value on the table to be
(1000 - 1)
and then performed a normal SQL insert without the
AUTO_INCREMENT field pid, we might be able avoid such issues.
CREATE TABLE `care_person` (
`pid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
The attached pre-test image is the situation just after table creation.
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
After execution of the said 3 sqls, the backup schema of the table is:
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL auto_increment,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
The attached mess image is taken after all the above SQLs have been
executed.
Regards,
Ap.Muthu
Sorry, I do not get the point. When you do that then you will have the
query result of LAST_INSERT_ID() 1001
There is on table definition an autoincrement and you give in your
insert statement an fixed value to it? The result is always strange
(guess it will be 1001 instead of 1000 - not tested so
far...why?)
Do do you want to make me busy? :-)
Robert
Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu:
Hi Robert,
Try to make the table without any records and the default AUTO_INCREMENT
to
start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted).
Then make an insert with a pid = 1000 in the insert statement and
check
the Last insert ID():
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
Regards,
Ap.Muthu
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue
on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not to
try with latest adbodb layer if that strange behaviour could be
covered
with it?
Robert
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
My test is under Debian Lenny
The SQL client was from Windows - SQLyog.
MySQL v5.0.51a-24+Lenny4
concurrent_insert = 1
innodb_commit_concurrency = 0
Hi,
I just tested it out here as well:
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.02 sec)
mysql INSERT INTO `care_person` (`pid`, `name`) VALUES (1000,
'Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
So we have a different behaviour under windows and linux. But I would no
like to have such autoincrement decrements (AI - 1) in the code
(readability, maintainability, reliability.. in case that this will be
fixed by mysql later it would be a real ugly workaround what might bring
working HIS outside in real trouble by updating mysql).
Before doing that, I would suggest to create an dummy record in
care_person. (if adodb does not support here any suggestion on that
issue)
Robert
Am Mittwoch, den 29.09.2010, 15:49 +0530 schrieb Ap.Muthu:
Hi Robert,
I have tested it to be a MySQL issue and not a ADOdb issue.
On execution of the said statements, I get the Last Insert ID as 0.
So our care2x code seems to be inserting this kind of insert sql.
Possibly if we altered the AUTO_INCREMENT value on the table to be
(1000 - 1)
and then performed a normal SQL insert without the
AUTO_INCREMENT field pid, we might be able avoid such issues.
CREATE TABLE `care_person` (
`pid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
The attached pre-test image is the situation just after table creation.
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
After execution of the said 3 sqls, the backup schema of the table is:
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL auto_increment,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
The attached mess image is taken after all the above SQLs have been
executed.
Regards,
Ap.Muthu
Sorry, I do not get the point. When you do that then you will have the
query result of LAST_INSERT_ID() 1001
There is on table definition an autoincrement and you give in your
insert statement an fixed value to it? The result is always strange
(guess it will be 1001 instead of 1000 - not tested so
far...why?)
Do do you want to make me busy? :-)
Robert
Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu:
Hi Robert,
Try to make the table without any records and the default
AUTO_INCREMENT
to
start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted).
Then make an insert with a pid = 1000 in the insert statement and
check
the Last insert ID():
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
Regards,
Ap.Muthu
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT
NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY
(`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue
on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not
to
try with latest adbodb layer if that strange behaviour could be
covered
with it?
Robert
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers mailing list
Care2002-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/care2002-developers
Re: [Care2002-developers] ADOdb Issues
veto! :-)
Either we have a reliable PID or not. When we register a patient it
should be give a uniqie PID, handled by sessions and db in the same way.
This is the once and only identifier for an patient record and we should
not make workarounds in it. All other patient demographic information
handled different on each requirement. (complex topic, but all here who
implemented an HIS in a real hospital know what I mean)
Think also that in most cases there are existing old HIS are running and
the data will be inserted by e.g. kettle-jobs and we are not starting to
use it from scratch.
I see just two options if we work on table layer (mysql_dump.sql):
Either we store an dummy record in it that MySQL has a previous PK
(maybe exactly that seems to me the issue in the different execution
plan of several MySQL-Servers) - or remove the Autoincrement of this
table and the scripts would take care of its unique character (worse and
dirty solution).
Alternatively to look if latest adodb has covered that issue. This is
not a new issue on the bug reports of mysql what I can see and that is
the reason to use adodb.
Robert
Am Mittwoch, den 29.09.2010, 16:13 +0530 schrieb Ap.Muthu:
If the following is executed before attempting to create a new first person
then the last insert id of adodb will work:
ALTER TABLE `care_person` AUTO_INCREMENT=999;
Hi Robert,
I have tested it to be a MySQL issue and not a ADOdb issue.
On execution of the said statements, I get the Last Insert ID as 0.
So our care2x code seems to be inserting this kind of insert sql.
Possibly if we altered the AUTO_INCREMENT value on the table to be
(1000 - 1)
and then performed a normal SQL insert without the
AUTO_INCREMENT field pid, we might be able avoid such issues.
CREATE TABLE `care_person` (
`pid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
The attached pre-test image is the situation just after table creation.
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
After execution of the said 3 sqls, the backup schema of the table is:
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL auto_increment,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
The attached mess image is taken after all the above SQLs have been
executed.
Regards,
Ap.Muthu
Sorry, I do not get the point. When you do that then you will have the
query result of LAST_INSERT_ID() 1001
There is on table definition an autoincrement and you give in your
insert statement an fixed value to it? The result is always strange
(guess it will be 1001 instead of 1000 - not tested so
far...why?)
Do do you want to make me busy? :-)
Robert
Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu:
Hi Robert,
Try to make the table without any records and the default AUTO_INCREMENT
to
start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted).
Then make an insert with a pid = 1000 in the insert statement and
check
the Last insert ID():
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
Regards,
Ap.Muthu
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue
on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not to
try with latest adbodb layer if that strange behaviour could be
covered
with it?
Robert
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Care2002-developers
Re: [Care2002-developers] ADOdb Issues
actually it's a bit more simple
the first time it executes the query the AUTOINCREMENT value is not set,
so it gets 0. the second time it works correctly.
now we have two solutions :
- in the sql creation script of the person table add an
AUTOINCREMENT=100
- or create a configuration value for the pid so the user can configure
it to suite
their needs.
gj.
On 2010-09-29 12:57.MD, Robert Meggle wrote:
veto! :-)
Either we have a reliable PID or not. When we register a patient it
should be give a uniqie PID, handled by sessions and db in the same way.
This is the once and only identifier for an patient record and we should
not make workarounds in it. All other patient demographic information
handled different on each requirement. (complex topic, but all here who
implemented an HIS in a real hospital know what I mean)
Think also that in most cases there are existing old HIS are running and
the data will be inserted by e.g. kettle-jobs and we are not starting to
use it from scratch.
I see just two options if we work on table layer (mysql_dump.sql):
Either we store an dummy record in it that MySQL has a previous PK
(maybe exactly that seems to me the issue in the different execution
plan of several MySQL-Servers) - or remove the Autoincrement of this
table and the scripts would take care of its unique character (worse and
dirty solution).
Alternatively to look if latest adodb has covered that issue. This is
not a new issue on the bug reports of mysql what I can see and that is
the reason to use adodb.
Robert
Am Mittwoch, den 29.09.2010, 16:13 +0530 schrieb Ap.Muthu:
If the following is executed before attempting to create a new first person
then the last insert id of adodb will work:
ALTER TABLE `care_person` AUTO_INCREMENT=999;
Hi Robert,
I have tested it to be a MySQL issue and not a ADOdb issue.
On execution of the said statements, I get the Last Insert ID as 0.
So our care2x code seems to be inserting this kind of insert sql.
Possibly if we altered the AUTO_INCREMENT value on the table to be
(1000 - 1)
and then performed a normal SQL insert without the
AUTO_INCREMENT field pid, we might be able avoid such issues.
CREATE TABLE `care_person` (
`pid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;
The attached pre-test image is the situation just after table creation.
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
After execution of the said 3 sqls, the backup schema of the table is:
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL auto_increment,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
The attached mess image is taken after all the above SQLs have been
executed.
Regards,
Ap.Muthu
Sorry, I do not get the point. When you do that then you will have the
query result of LAST_INSERT_ID() 1001
There is on table definition an autoincrement and you give in your
insert statement an fixed value to it? The result is always strange
(guess it will be 1001 instead of 1000 - not tested so
far...why?)
Do do you want to make me busy? :-)
Robert
Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu:
Hi Robert,
Try to make the table without any records and the default AUTO_INCREMENT
to
start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted).
Then make an insert with a pid = 1000 in the insert statement and
check
the Last insert ID():
CREATE TABLE `care_person` (
`pid` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
PRIMARY KEY (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert');
SELECT LAST_INSERT_ID();
Regards,
Ap.Muthu
...I tested out with mysql client and standard call, and it worked
perfectly:
mysql create database dropme;
Query OK, 1 row affected (0.02 sec)
mysql \u dropme
Database changed
mysql CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL
AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) )
ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.06 sec)
mysql insert into care_person (name) VALUES ('Donald');
Query OK, 1 row affected (0.00 sec)
mysql SELECT LAST_INSERT_ID();
+--+
| LAST_INSERT_ID() |
+--+
| 1001 |
+--+
1 row in set (0.00 sec)
That would mean as logic consequence: MySQL does not have that issue
on
my ubuntu here. But the behaviour of adodb method Insert_ID() had
reproducibly that issue on the same ubuntu. Is there any reason not to
try with latest adbodb layer if that strange behaviour could be
covered
with it?
Robert
Re: [Care2002-developers] ADOdb Issues
The existing fix to use the POST value seems best under the circumstances for a first jump in auto increment value. As this is a purely MySQL version dependant issue, lets leave it at that for now but keep our eyes open for any similar jumps in auto increment values. Actually, the Auto increment value set in a table's config is the next available pk id to be issued. Hence (1000 - 1) is not needed and just: ALTER TABLE `care_person` AUTO_INCREMENT=1000; is sufficient. Nevertheless, it is best to rely on the POST variable set with php logic and config table value - for the first entry for a jump in pk id. Regards, Ap.Muthu - Original Message - From: Gjergj Sheldija gjergj.sheld...@gmail.com To: care2002-developers@lists.sourceforge.net Sent: Wednesday, September 29, 2010 4:35 PM Subject: Re: [Care2002-developers] ADOdb Issues actually it's a bit more simple the first time it executes the query the AUTOINCREMENT value is not set, so it gets 0. the second time it works correctly. now we have two solutions : - in the sql creation script of the person table add an AUTOINCREMENT=100 - or create a configuration value for the pid so the user can configure it to suite their needs. gj. On 2010-09-29 12:57.MD, Robert Meggle wrote: veto! :-) Either we have a reliable PID or not. When we register a patient it should be give a uniqie PID, handled by sessions and db in the same way. This is the once and only identifier for an patient record and we should not make workarounds in it. All other patient demographic information handled different on each requirement. (complex topic, but all here who implemented an HIS in a real hospital know what I mean) Think also that in most cases there are existing old HIS are running and the data will be inserted by e.g. kettle-jobs and we are not starting to use it from scratch. I see just two options if we work on table layer (mysql_dump.sql): Either we store an dummy record in it that MySQL has a previous PK (maybe exactly that seems to me the issue in the different execution plan of several MySQL-Servers) - or remove the Autoincrement of this table and the scripts would take care of its unique character (worse and dirty solution). Alternatively to look if latest adodb has covered that issue. This is not a new issue on the bug reports of mysql what I can see and that is the reason to use adodb. Robert Am Mittwoch, den 29.09.2010, 16:13 +0530 schrieb Ap.Muthu: If the following is executed before attempting to create a new first person then the last insert id of adodb will work: ALTER TABLE `care_person` AUTO_INCREMENT=999; Hi Robert, I have tested it to be a MySQL issue and not a ADOdb issue. On execution of the said statements, I get the Last Insert ID as 0. So our care2x code seems to be inserting this kind of insert sql. Possibly if we altered the AUTO_INCREMENT value on the table to be (1000 - 1) and then performed a normal SQL insert without the AUTO_INCREMENT field pid, we might be able avoid such issues. CREATE TABLE `care_person` ( `pid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, `name` VARCHAR(60) NOT NULL, PRIMARY KEY (`pid`) ) ENGINE=INNODB DEFAULT CHARSET=utf8; The attached pre-test image is the situation just after table creation. INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert'); SELECT LAST_INSERT_ID(); After execution of the said 3 sqls, the backup schema of the table is: CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL auto_increment, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) ) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8; The attached mess image is taken after all the above SQLs have been executed. Regards, Ap.Muthu Sorry, I do not get the point. When you do that then you will have the query result of LAST_INSERT_ID() 1001 There is on table definition an autoincrement and you give in your insert statement an fixed value to it? The result is always strange (guess it will be 1001 instead of 1000 - not tested so far...why?) Do do you want to make me busy? :-) Robert Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu: Hi Robert, Try to make the table without any records and the default AUTO_INCREMENT to start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted). Then make an insert with a pid = 1000 in the insert statement and check the Last insert ID(): CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert'); SELECT LAST_INSERT_ID(); Regards, Ap.Muthu ...I tested out with mysql client and standard call, and it worked perfectly: mysql create database dropme; Query OK, 1 row affected (0.02 sec) mysql \u dropme Database changed
Re: [Care2002-developers] ADOdb Issues
Hi Muthu, Yes, that is perfect. Just thinking now if the workaround from yesterday night would do that job now out of the box? $pid is empty, so it would be the session pid been used... I have to test it later today. Sorry... Robert Am Mittwoch, den 29.09.2010, 17:37 +0530 schrieb Ap.Muthu: The existing fix to use the POST value seems best under the circumstances for a first jump in auto increment value. As this is a purely MySQL version dependant issue, lets leave it at that for now but keep our eyes open for any similar jumps in auto increment values. Actually, the Auto increment value set in a table's config is the next available pk id to be issued. Hence (1000 - 1) is not needed and just: ALTER TABLE `care_person` AUTO_INCREMENT=1000; is sufficient. Nevertheless, it is best to rely on the POST variable set with php logic and config table value - for the first entry for a jump in pk id. Regards, Ap.Muthu - Original Message - From: Gjergj Sheldija gjergj.sheld...@gmail.com To: care2002-developers@lists.sourceforge.net Sent: Wednesday, September 29, 2010 4:35 PM Subject: Re: [Care2002-developers] ADOdb Issues actually it's a bit more simple the first time it executes the query the AUTOINCREMENT value is not set, so it gets 0. the second time it works correctly. now we have two solutions : - in the sql creation script of the person table add an AUTOINCREMENT=100 - or create a configuration value for the pid so the user can configure it to suite their needs. gj. On 2010-09-29 12:57.MD, Robert Meggle wrote: veto! :-) Either we have a reliable PID or not. When we register a patient it should be give a uniqie PID, handled by sessions and db in the same way. This is the once and only identifier for an patient record and we should not make workarounds in it. All other patient demographic information handled different on each requirement. (complex topic, but all here who implemented an HIS in a real hospital know what I mean) Think also that in most cases there are existing old HIS are running and the data will be inserted by e.g. kettle-jobs and we are not starting to use it from scratch. I see just two options if we work on table layer (mysql_dump.sql): Either we store an dummy record in it that MySQL has a previous PK (maybe exactly that seems to me the issue in the different execution plan of several MySQL-Servers) - or remove the Autoincrement of this table and the scripts would take care of its unique character (worse and dirty solution). Alternatively to look if latest adodb has covered that issue. This is not a new issue on the bug reports of mysql what I can see and that is the reason to use adodb. Robert Am Mittwoch, den 29.09.2010, 16:13 +0530 schrieb Ap.Muthu: If the following is executed before attempting to create a new first person then the last insert id of adodb will work: ALTER TABLE `care_person` AUTO_INCREMENT=999; Hi Robert, I have tested it to be a MySQL issue and not a ADOdb issue. On execution of the said statements, I get the Last Insert ID as 0. So our care2x code seems to be inserting this kind of insert sql. Possibly if we altered the AUTO_INCREMENT value on the table to be (1000 - 1) and then performed a normal SQL insert without the AUTO_INCREMENT field pid, we might be able avoid such issues. CREATE TABLE `care_person` ( `pid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, `name` VARCHAR(60) NOT NULL, PRIMARY KEY (`pid`) ) ENGINE=INNODB DEFAULT CHARSET=utf8; The attached pre-test image is the situation just after table creation. INSERT INTO `care_person` (`pid`, `name`) VALUES (1000, 'Robert'); SELECT LAST_INSERT_ID(); After execution of the said 3 sqls, the backup schema of the table is: CREATE TABLE `care_person` ( `pid` int(11) unsigned NOT NULL auto_increment, `name` varchar(60) NOT NULL, PRIMARY KEY (`pid`) ) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8; The attached mess image is taken after all the above SQLs have been executed. Regards, Ap.Muthu Sorry, I do not get the point. When you do that then you will have the query result of LAST_INSERT_ID() 1001 There is on table definition an autoincrement and you give in your insert statement an fixed value to it? The result is always strange (guess it will be 1001 instead of 1000 - not tested so far...why?) Do do you want to make me busy? :-) Robert Am Mittwoch, den 29.09.2010, 15:12 +0530 schrieb Ap.Muthu: Hi Robert, Try to make the table without any records and the default AUTO_INCREMENT to start with should be 1 (if the parameter AUTO_INCREMENT=1is omitted). Then make an insert with a pid = 1000 in the insert statement and check the Last insert ID(): CREATE TABLE `care_person` ( `pid` int(11
