|
NAMEDBD::Sybase - Sybase database driver for the DBI moduleSYNOPSISuse DBI; $dbh = DBI->connect("dbi:Sybase:", $user, $passwd); # See the DBI module documentation for full details DESCRIPTIONDBD::Sybase is a Perl module which works with the DBI module to provide access to Sybase databases.Connecting to SybaseThe interfaces fileThe DBD::Sybase module is built on top of the Sybase Open Client Client Library API. This library makes use of the Sybase interfaces file (sql.ini on Win32 machines) to make a link between a logical server name (e.g. SYBASE) and the physical machine / port number that the server is running on. The OpenClient library uses the environment variable SYBASE to find the location of the interfaces file, as well as other files that it needs (such as locale files). The SYBASE environment is the path to the Sybase installation (eg '/usr/local/sybase'). If you need to set it in your scripts, then you must set it in a "BEGIN{}" block:BEGIN { $ENV{SYBASE} = '/opt/sybase/11.0.2'; } my $dbh = DBI->connect('dbi:Sybase:', $user, $passwd); Specifying the server nameThe server that DBD::Sybase connects to defaults to SYBASE, but can be specified in two ways.You can set the DSQUERY environement variable: $ENV{DSQUERY} = "ENGINEERING"; $dbh = DBI->connect('dbi:Sybase:', $user, $passwd); Or you can pass the server name in the first argument to connect(): $dbh = DBI->connect("dbi:Sybase:server=ENGINEERING", $user, $passwd); Specifying other connection specific parametersIt is sometimes necessary (or beneficial) to specify other connection properties. Currently the following are supported:
These different parameters (as well as the server name) can be strung together by separating each entry with a semi-colon: $dbh = DBI->connect("dbi:Sybase:server=ENGINEERING;packetSize=8192;language=us_english;charset=iso_1", $user, $pwd); Handling Multiple Result SetsSybase's Transact SQL has the ability to return multiple result sets from a single SQL statement. For example the query:select b.title, b.author, s.amount from books b, sales s where s.authorID = b.authorID order by b.author, b.title compute sum(s.amount) by b.author which lists sales by author and title and also computes the total sales by author returns two types of rows. The DBI spec doesn't really handle this situation, nor the more hairy exec my_proc @p1='this', @p2='that', @p3 out where "my_proc" could return any number of result sets (ie it could perform an unknown number of "select" statements. I've decided to handle this by returning an empty row at the end of each result set, and by setting a special Sybase attribute in $sth which you can check to see if there is more data to be fetched. The attribute is syb_more_results which you should check to see if you need to re-start the "fetch()" loop. To make sure all results are fetched, the basic "fetch" loop can be written like this: { while($d = $sth->fetch) { ... do something with the data } redo if $sth->{syb_more_results}; } You can get the type of the current result set with $sth->{syb_result_type}. This returns a numerical value, as defined in $SYBASE/$SYBASE_OCS/include/cspublic.h: #define CS_ROW_RESULT (CS_INT)4040 #define CS_CURSOR_RESULT (CS_INT)4041 #define CS_PARAM_RESULT (CS_INT)4042 #define CS_STATUS_RESULT (CS_INT)4043 #define CS_MSG_RESULT (CS_INT)4044 #define CS_COMPUTE_RESULT (CS_INT)4045 In particular, the return status of a stored procedure is returned as CS_STATUS_RESULT (4043), and is normally the last result set that is returned in a stored proc execution, but see the syb_do_proc_status attribute for an alternative way of handling this result type. See Executing Stored Procedures elsewhere in this document for more information. If you add a use DBD::Sybase; to your script then you can use the symbolic values (CS_xxx_RESULT) instead of the numeric values in your programs, which should make them easier to read. See also the "$sth-"syb_output_params> call to handle stored procedures that only return OUTPUT parameters. $sth->execute() failure mode behaviorDBD::Sybase has the ability to handle multi-statement SQL commands in a single batch. For example, you could insert several rows in a single batch like this:$sth = $dbh->prepare(" insert foo(one, two, three) values(1, 2, 3) insert foo(one, two, three) values(4, 5, 6) insert foo(one, two, three) values(10, 11, 12) insert foo(one, two, three) values(11, 12, 13) "); $sth->execute; If any one of the above inserts fails for any reason then $sth->execute will return "undef", HOWEVER the inserts that didn't fail will still be in the database, unless "AutoCommit" is off. It's also possible to write a statement like this: $sth = $dbh->prepare(" insert foo(one, two, three) values(1, 2, 3) select * from bar insert foo(one, two, three) values(10, 11, 12) "); $sth->execute; If the second "insert" is the one that fails, then $sth->execute will NOT return "undef". The error will get flagged after the rows from "bar" have been fetched. I know that this is not as intuitive as it could be, but I am constrained by the Sybase API here. As an aside, I know that the example above doesn't really make sense, but I need to illustrate this particular sequence... You can also see the t/fail.t test script which shows this particular behavior. Sybase Specific AttributesThere are a number of handle attributes that are specific to this driver. These attributes all start with syb_ so as to not clash with any normal DBI attributes.Database Handle AttributesThe following Sybase specific attributes can be set at the Database handle level:
Statement Handle AttributesThe following read-only attributes are available at the statement level:
Controlling DATETIME output formatsBy default DBD::Sybase will return DATETIME and SMALLDATETIME columns in the Nov 15 1998 11:13AM format. This can be changed via a private syb_date_fmt() method.The syntax is $dbh->syb_date_fmt($fmt); where $fmt is a string representing the format that you want to apply. Note that this requires DBI 1.37 or later. The formats are based on Sybase's standard conversion routines. The following subset of available formats has been implemented:
Retrieving OUTPUT parameters from stored proceduresSybase lets you pass define OUTPUT parameters to stored procedures, which are a little like parameters passed by reference in C (or perl.)In Transact-SQL this is done like this declare @id_value int, @id_name char(10) exec my_proc @name = 'a string', @number = 1234, @id = @id_value OUTPUT, @out_name = @id_name OUTPUT -- Now @id_value and @id_name are set to whatever 'my_proc' set @id and @out_name to So how can we get at @param using DBD::Sybase? If your stored procedure only returns OUTPUT parameters, then you can use this shorthand: $sth = $dbh->prepare('...'); $sth->execute; @results = $sth->syb_output_params(); This will return an array for all the OUTPUT parameters in the proc call, and will ignore any other results. The array will be undefined if there are no OUTPUT params, or if the stored procedure failed for some reason. The more generic way looks like this: $sth = $dbh->prepare("declare \@id_value int, \@id_name exec my_proc @name = 'a string', @number = 1234, @id = @id_value OUTPUT, @out_name = @id_name OUTPUT"); $sth->execute; { while($d = $sth->fetch) { if($sth->{syb_result_type} == 4042) { # it's a PARAM result $id_value = $d->[0]; $id_name = $d->[1]; } } redo if $sth->{syb_more_results}; } So the OUTPUT params are returned as one row in a special result set. Multiple active statements on one $dbhIt is possible to open multiple active statements on a single database handle. This is done by opening a new physical connection in $dbh->prepare() if there is already an active statement handle for this $dbh.This feature has been implemented to improve compatibility with other drivers, but should not be used if you are coding directly to the Sybase driver. The "syb_no_child_con" attribute controls whether this feature is turned on. If it is FALSE (the default), then multiple statement handles are supported. If it is TRUE then multiple statements on the same database handle are disabled. Also see below for interaction with AutoCommit. If AutoCommit is OFF then multiple statement handles on a single $dbh is NOT supported. This is to avoid various deadlock problems that can crop up in this situation, and because you will not get real transactional integrity using multiple statement handles simultaneously as these in reality refer to different physical connections. Working with IMAGE and TEXT columnsDBD::Sybase can store and retrieve IMAGE or TEXT data (aka "blob" data) via standard SQL statements. The LongReadLen handle attribute controls the maximum size of IMAGE or TEXT data being returned for each data element.When using standard SQL the default for IMAGE data is to be converted to a hex string, but you can use the syb_binary_images handle attribute to change this behaviour. Alternatively you can use something like $binary = pack("H*", $hex_string); to do the conversion. IMAGE and TEXT datatypes can not be passed as parameters using ?-style placeholders, and placeholders can't refer to IMAGE or TEXT columns (this is a limitation of the TDS protocol used by Sybase, not a DBD::Sybase limitation.) There is an alternative way to access and update IMAGE/TEXT data using the natice OpenClient API. This is done via $h->func() calls, and is, unfortunately, a little convoluted. Handling IMAGE/TEXT data with syb_ct_get_data()/syb_ct_send_data()With DBI 1.37 and later you can call all of these ct_xxx() calls directly as statement handle methods by prefixing them with syb_, so for example$sth->func($col, $dataref, $numbytes, 'ct_fetch_data'); becomes $sth->syb_ct_fetch_data($col, $dataref, $numbytes);
AutoCommit, Transactions and Transact-SQLWhen $h->{AutoCommit} is off all data modification SQL statements that you issue (insert/update/delete) will only take effect if you call $dbh->commit.DBD::Sybase implements this via two distinct methods, depending on the setting of the $h->{syb_chained_txn} attribute and the version of the server that is being accessed. If $h->{syb_chained_txn} is off, then the DBD::Sybase driver will send a BEGIN TRAN before the first $dbh->prepare(), and after each call to $dbh->commit() or $dbh->rollback(). This works fine, but will cause any SQL that contains any CREATE TABLE (or other DDL) statements to fail. These CREATE TABLE statements can be burried in a stored procedure somewhere (for example, "sp_helprotect" creates two temp tables when it is run). You can get around this limit by setting the "ddl in tran" option (at the database level, via "sp_dboption".) You should be aware that this can have serious effects on performance as this causes locks to be held on certain system tables for the duration of the transaction. If $h->{syb_chained_txn} is on, then DBD::Sybase sets the CHAINED option, which tells Sybase not to commit anything automatically. Again, you will need to call $dbh->commit() to make any changes to the data permanent. Behavior of $dbh->last_insert_idThis version of DBD::Sybase includes support for the last_insert_id() call, with the following caveats:The last_insert_id() call is simply a wrapper around a "select @@identity" query. To be successful (i.e. to return the correct value) this must be executed on the same connection as the INSERT that generated the new IDENTITY value. Therefore the statement handle that was used to perform the insert must have been closed/freed before last_insert_id() can be called. Otherwise last_insert_id() will be forced to open a different connection to perform the query, and will return an invalid value (usually in this case it will return 0). last_insert_id() ignores any parameters passed to it, and will NOT return the last @@identity value generated in the case where placeholders were used, or where the insert was encapsulated in a stored procedure. Using ? Placeholders & bind parameters to $sth->executeDBD::Sybase supports the use of ? placeholders in SQL statements as long as the underlying library and database engine supports it. It does this by using what Sybase calls Dynamic SQL. The ? placeholders allow you to write something like:$sth = $dbh->prepare("select * from employee where empno = ?"); # Retrieve rows from employee where empno == 1024: $sth->execute(1024); while($data = $sth->fetch) { print "@$data\n"; } # Now get rows where empno = 2000: $sth->execute(2000); while($data = $sth->fetch) { print "@$data\n"; } When you use ? placeholders Sybase goes and creates a temporary stored procedure that corresponds to your SQL statement. You then pass variables to $sth->execute or $dbh->do, which get inserted in the query, and any rows are returned. DBD::Sybase uses the underlying Sybase API calls to handle ?-style placeholders. For select/insert/update/delete statements DBD::Sybase calls the ct_dynamic() family of Client Library functions, which gives DBD::Sybase data type information for each parameter to the query. You can only use ?-style placeholders for statements that return a single result set, and the ? placeholders can only appear in a WHERE clause, in the SET clause of an UPDATE statement, or in the VALUES list of an INSERT statement. The DBI docs mention the following regarding NULL values and placeholders: Binding an `undef' (NULL) to the placeholder will not select rows which have a NULL `product_code'! Refer to the SQL manual for your database engine or any SQL book for the reasons for this. To explicitly select NULLs you have to say "`WHERE product_code IS NULL'" and to make that general you have to say: ... WHERE (product_code = ? OR (? IS NULL AND product_code IS NULL)) and bind the same value to both placeholders. This will not work with a Sybase database server. If you attempt the above construct you will get the following error: The datatype of a parameter marker used in the dynamic
prepare statement could not be resolved.
The specific problem here is that when using ? placeholders the prepare() operation is sent to the database server for parameter resoltion. This extracts the datatypes for each of the placeholders. Unfortunately the "? is null" construct doesn't tie the ? placeholder with an existing table column, so the database server can't find the data type. As this entire operation happens inside the Sybase libraries there is no easy way for DBD::Sybase to work around it. Note that Sybase will normally handle the "foo = NULL" construct the same way that other systems handle "foo is NULL", so the convoluted construct that is described above is not necessary to obtain the correct results when querying a Sybase database. The underlying API does not support ?-style placeholders for stored procedures, but see the section on titled Stored Procedures and Placeholders elsewhere in this document. ?-style placeholders can NOT be used to pass TEXT or IMAGE data items to the server. This is a limitation of the TDS protocol, not of DBD::Sybase. There is also a performance issue: OpenClient creates stored procedures in tempdb for each prepare() call that includes ? placeholders. Creating these objects requires updating system tables in the tempdb database, and can therefore create a performance hotspot if a lot of prepare() statements from multiple clients are executed simultaneously. This problem has been corrected for Sybase 11.9.x and later servers, as they create "lightweight" temporary stored procs which are held in the server memory cache and don't affect the system tables at all. In general however I find that if your application is going to run against Sybase it is better to write ad-hoc stored procedures rather than use the ? placeholders in embedded SQL. Out of curiosity I did some simple timings to see what the overhead of doing a prepare with ? placehoders is vs. a straight SQL prepare and vs. a stored procedure prepare. Against an 11.0.3.3 server (linux) the placeholder prepare is significantly slower, and you need to do ~30 execute() calls on the prepared statement to make up for the overhead. Against a 12.0 server (solaris) however the situation was very different, with placeholder prepare() calls slightly faster than straight SQL prepare(). This is something that I really don't understand, but the numbers were pretty clear. In all cases stored proc prepare() calls were clearly faster, and consistently so. This test did not try to gauge concurrency issues, however. It is not possible to retrieve the last IDENTITY value after an insert done with ?-style placeholders. This is a Sybase limitation/bug, not a DBD::Sybase problem. For example, assuming table foo has an identity column: $dbh->do("insert foo(col1, col2) values(?, ?)", undef, "string1", "string2"); $sth = $dbh->prepare('select @@identity') || die "Can't prepare the SQL statement: $DBI::errstr"; $sth->execute || die "Can't execute the SQL statement: $DBI::errstr"; #Get the data back. while (my $row = $sth->fetchrow_arrayref()) { print "IDENTITY value = $row->[0]\n"; } will always return an identity value of 0, which is obviously incorrect. This behaviour is due to the fact that the handling of ?-style placeholders is implemented using temporary stored procedures in Sybase, and the value of @@identity is reset when the stored procedure has executed. Using an explicit stored procedure to do the insert and trying to retrieve @@identity after it has executed results in the same behaviour. Please see the discussion on Dynamic SQL in the OpenClient C Programmer's Guide for details. The guide is available on-line at http://sybooks.sybase.com/ Calling Stored ProceduresDBD::Sybase handles stored procedures in the same way as any other Transact-SQL statement. The only real difference is that Sybase stored procedures always return an extra result set with the return status from the proc which corresponds to the return statement in the stored procedure code. This result set with a single row is always returned last and has a result type of CS_STATUS_RESULT (4043).By default this result set is returned like any other, but you can ask DBD::Sybase to process it under the covers via the $h->{syb_do_proc_status} attribute. If this attribute is set then DBD::Sybase will process the CS_STATUS_RESULT result set itself, place the return status value in $sth->{syb_proc_status}, and possibly raise an error if the result set is different from 0. Note that a non-0 return status will NOT cause $sth->execute to return a failure code if the proc has at least one other result set that returned rows (reason: the rows are returned and fetched before the return status is seen). Stored Procedures and PlaceholdersDBD::Sybase has the ability to use ?-style placeholders as parameters to stored proc calls. The requirements are that the stored procedure call be initiated with an "exec" and that it be the only statement in the batch that is being prepared():For example, this prepares a stored proc call with named parameters: my $sth = $dbh->prepare("exec my_proc \@p1 = ?, \@p2 = ?"); $sth->execute('one', 'two'); You can also use positional parameters: my $sth = $dbh->prepare("exec my_proc ?, ?"); $sth->execute('one', 'two'); You may not mix positional and named parameter in the same prepare. You can't mix placeholder parameters and hard coded parameters. For example $sth = $dbh->prepare("exec my_proc \@p1 = 1, \@p2 = ?"); will not work - because the @p1 parameter isn't parsed correctly and won't be sent to the server. You can specify OUTPUT parameters in the usual way, but you can NOT use bind_param_inout() to get the output result - instead you have to call fetch() and/or $sth->func('syb_output_params'): my $sth = $dbh->prepare("exec my_proc \@p1 = ?, \@p2 = ?, \@p3 = ? OUTPUT "); $sth->execute('one', 'two', 'three'); my (@data) = $sth->syb_output_params(); DBD::Sybase does not attempt to figure out the correct parameter type for each parameter (it would be possible to do this for most cases, but there are enough exceptions that I preferred to avoid the issue for the time being). DBD::Sybase defaults all the parameters to SQL_CHAR, and you have to use bind_param() with an explicit type value to set this to something different. The type is then remembered, so you only need to use the explicit call once for each parameter: my $sth = $dbh->prepare("exec my_proc \@p1 = ?, \@p2 = ?"); $sth->bind_param(1, 'one', SQL_CHAR); $sth->bind_param(2, 2.34, SQL_FLOAT); $sth->execute; .... $sth->execute('two', 3.456); etc... Note that once a type has been defined for a parameter you can't change it. When binding SQL_NUMERIC or SQL_DECIMAL data you may get fatal conversion errors if the scale or the precision exceeds the size of the target parameter definition. For example, consider the following stored proc definition: declare proc my_proc @p1 numeric(5,2) as... and the following prepare/execute snippet: my $sth = $dbh->prepare("exec my_proc \@p1 = ?"); $sth->bind_param(1, 3.456, SQL_NUMERIC); This generates the following error: DBD::Sybase::st execute failed: Server message number=241 severity=16 state=2 line=0 procedure=dbitest text=Scale error during implicit conversion of NUMERIC value '3.456' to a NUMERIC field. You can tell Sybase (and DBD::Sybase) to ignore these sorts of errors by setting the arithabort option: $dbh->do("set arithabort off"); See the set command in the Sybase Adaptive Server Enterprise Reference Manual for more information on the set command and on the arithabort option. Other Private MethodsDBD::Sybase private Database Handle Methods
DBD::Sybase private Statement Handle Methods
Experimental Bulk-Load FunctionalityNOTE: This feature requires that the libblk.a library be available at build time. This is not always the case if the Sybase SDK isn't installed. You can test the $dbh->{syb_has_blk} attribute to see if the BLK api calls are available in your copy of DBD::Sybase.Starting with release 1.04.2 DBD::Sybase has the ability to use Sybase's BLK (bulk-loading) API to perform fast data loads. Basic usage is as follows: my $dbh = DBI->connect('dbi:Sybase:server=MY_SERVER;bulkLogin=1', $user, $pwd); $dbh->begin_work; # optional. my $sth = $dbh->prepare("insert the_table values(?, ?, ?, ?, ?)", {syb_bcp_attribs => { identity_flag => 0, identity_column => 0 }}}); while(<DATA>) { chomp; my @row = split(/\|/, $_); # assume a pipe-delimited file... $sth->execute(@row); } $dbh->commit; print "Sent ", $sth->rows, " to the server\n"; $sth->finish; First, you need to specify the new bulkLogin attribute in the connection string, which turns on the CS_BULK_LOGIN property for the connection. Without this property the BLK api will not be functional. You call $dbh->prepare() with a regular INSERT statement and the special syb_bcp_attribs attribute to turn on BLK handling of the data. The identity_flag sub-attribute can be set to 1 if your source data includes the values for the target table's IDENTITY column. If the target table has an IDENTITY column but you want the insert operation to generate a new value for each row then leave identity_flag at 0, but set identity_col to the column number of the identity column (it's usually the first column in the table, but not always.) The number of placeholders in the INSERT statement must correspond to the number of columns in the table, and the input data must be in the same order as the table's physical column order. Any column list in the INSERT statement (i.e. insert table(a, b, c,...) values(...) is ignored. The value of AutoCommit is ignored for BLK operations - rows are only commited when you call $dbh->commit. You can call $dbh->rollback to cancel any uncommited rows, but this also cancels the rest of the BLK operation: any attempt to load rows to the server after a call to $dbh->rollback() will fail. If a row fails to load due to a CLIENT side error (such as a data conversion error) then $sth->execute() will return a failure (i.e. false) and $sth->errstr will have the reason for the error. If a row fails on the SERVER side (for example due to a duplicate row error) then the entire batch (i.e. between two $dbh->commit() calls) will fail. This is normal behavior for BLK/bcp. The Bulk-Load API is very sensitive to data conversion issues, as all the conversions are handled on the client side, and the row is pre-formatted before being sent to the server. By default any conversion that is flagged by Sybase's cs_convert() call will result in a failed row. Some of these conversion errors are patently fatal (e.g. converting 'Feb 30 2001' to a DATETIME value...), while others are debatable (e.g. converting 123.456 to a NUMERIC(6,2) which results in a loss of precision). The default behavior of failing any row that has a conversion error in it can be modified by using a special error handler. Returning 0 from this handler tells DBD::Sybase to fail this row, and returning 1 means that we still want to try to send the row to the server (obviously Sybase's internal code can still fail the row at that point.) You set the handler like this: DBD::Sybase::syb_set_cslib_cb(\&handler); and a sample handler: sub cslib_handler { my ($layer, $origin, $severity, $errno, $errmsg, $osmsg, $blkmsg) = @_; print "Layer: $layer, Origin: $origin, Severity: $severity, Error: $errno\n"; print $msg; print $osmsg if($osmsg); print $blkmsg if $blkmsg; return 1 if($errno == 36) return 0; } Please see the t/xblk.t test script for some examples. Reminder - this is an experimental implementation. It may change in the future, and it could be buggy. Using DBD::Sybase with MS-SQLMS-SQL started out as Sybase 4.2, and there are still a lot of similarities between Sybase and MS-SQL which makes it possible to use DBD::Sybase to query a MS-SQL dataserver using either the Sybase OpenClient libraries or the FreeTDS libraries (see http://www.freetds.org).However, using the Sybase libraries to query an MS-SQL server has certain limitations. In particular ?-style placeholders are not supported (although support when using the FreeTDS libraries is possible in a future release of the libraries), and certain syb_ attributes may not be supported. Sybase defaults the TEXTSIZE attribute (aka LongReadLen) to 32k, but MS-SQL 7 doesn't seem to do that correctly, resulting in very large memory requests when querying tables with TEXT/IMAGE data columns. The work-around is to set TEXTSIZE to some decent value via $dbh->{LongReadLen} (if that works - I haven't had any confirmation that it does) or via $dbh->do("set textsize <somesize>"); nsqlThe nsql() call is a direct port of the function of the same name that exists in Sybase::DBlib. From 1.08 it has been extended to offer new functionality.Usage: @data = $dbh->func($sql, $type, $callback, $options, 'nsql'); If the DBI version is 1.37 or later, then you can also call it this way: @data = $dbh->syb_nsql($sql, $type, $callback, $options); This executes the query in $sql, and returns all the data in @data. The $type parameter can be used to specify that each returned row be in array form (i.e. $type passed as 'ARRAY', which is the default) or in hash form ($type passed as 'HASH') with column names as keys. If $callback is specified it is taken as a reference to a perl sub, and each row returned by the query is passed to this subroutine instead of being returned by the routine (to allow processing of large result sets, for example). If $options is specified and is a HASH ref, the following keys affect the value returned by nsql():
Note that if $callback is omitted, a hash reference in that parameter position will be interpreted as an option hash if no hash reference is found in the $options parameter position. "nsql" also checks three special attributes to enable deadlock retry logic (Note none of these attributes have any effect anywhere else at the moment):
Deadlock detection will be added to the $dbh->do() method in a future version of DBD::Sybase. Multi-ThreadingDBD::Sybase is thread-safe (i.e. can be used in a multi-threaded perl application where more than one thread accesses the database server) with the following restrictions:
You can check to see if your version of DBD::Sybase is thread-safe at run-time by calling DBD::Sybase::thread_enabled(). This will return true if multi-threading is available. See t/thread.t for a simple example. BUGSYou can run out of space in the tempdb database if you use a lot of calls with bind variables (ie ?-style placeholders) without closing the connection and Sybase 11.5.x or older. This is because Sybase creates stored procedures for each prepare() call. In 11.9.x and later Sybase will create "light-weight" stored procedures which don't use up any space in the tempdb database.The primary_key_info() method will only return data for tables where a declarative "primary key" constraint was included when the table was created. I have a simple bug tracking database at http://www.peppler.org/bugdb/ . You can use it to view known problems, or to report new ones. SEE ALSODBISybase OpenClient C manuals. Sybase Transact SQL manuals. AUTHORDBD::Sybase by Michael PepplerCOPYRIGHTThe DBD::Sybase module is Copyright (c) 1996-2007 Michael Peppler. The DBD::Sybase module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.ACKNOWLEDGEMENTSTim Bunce for DBI, obviously!See also "ACKNOWLEDGEMENTS" in DBI. POD ERRORSHey! The above document had some coding errors, which are explained below:
Visit the GSP FreeBSD Man Page Interface. |