Running it without creating the tables first generates the following error:
ct_result(ct_dynamic(CS_PREPARE)) returned -205 at /usr/lib/perl5/site +_perl/5.6.0/i386-linux/DBD/Sybase.pm line 105. DBIx::Sequence: Server message number=208 severity=16 state=1 line=1 s +erver=trollprocedure=DBD1text=dbix_sequence_state not found. Specify +owner.objectname or use sp_help to check whether the object exists (s +p_help may produce lots of output). at ./sequence.pl line 5
Creating the tables manually and running a basic loop to get new IDs generates the following error:
The reason for this is that this module doesn't properly fetch all results after executing queries - and this leaves the various statement handles that it creates in an unstable state when used with DBD::Sybase.ct_param() failed! at /usr/lib/perl5/site_perl/5.6.0/DBIx/Sequence.pm +line 257. DBIx::Sequence: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY += (1) NUMBER = (16) Message String: ct_param(): user api layer: external error: This routi +ne cannot be called while results are pending for a command that has +been sent to the server. at ./sequence.pl line 11
In addition, pre-preparing 5 or 6 queries works really well with Oracle, but is not a good idea with Sybase, because this will open 5 or 6 connections to the server for each instance of DBIx::Sequence.
After patching the code so that it will work with Sybase I ran three concurrent processes that did nothing but fetch new IDs. The result was that only one process actually got any IDs - the other two were effectively locked out. Admittedly this is an extreme use of the module, but it does show the limits that this technique can have.
Michael
In reply to Re^4: portable mysql auto_increment
by mpeppler
in thread portable mysql auto_increment
by schweini
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |