Project

General

Profile

Bug #2589

remote request for next primary key gives wrong result when metadata DB is running

Added by Eric Faulhaber about 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

History

#1 Updated by Eric Faulhaber about 9 years ago

Requesting a next primary key for a database controlled by a remote server returns very low id numbers, typically starting at 10001, when that remote server has an embedded metadata database. I suspect the remote multiplexing is somehow connecting to the identity manager of the remote metadata database to serve primary keys, rather than to that of the remote primary database.

This eventually will result in a violation on the primary key constraint of the table for which a new record is being created. A server restart appears to reset the starting key, even if the associated record was stored in the primary database during the previous server session, presumably because the current metadata implementation creates a transient database whereby all primary keys in use are lost when the server shuts down.

Also available in: Atom PDF