Hello all, i am searching how to install a module but the question is : howto specify CPAN to install a determined version of the module? In my case i want to install DBD:Oracle1. Any idea welcome! Install Perl Module. Hi Every one, I am suing solaris 5. Thank you for your Help Thanks, Hari. Perl DBI install with gcc compiler. I want to install the Perl DBI module on to my solaris ultra Solaris ultra 10 does not come with a C compiler so I downloaded gcc compiler.
Then I ran install as follows: cd DBI RedHat Commands. OpenSolaris Commands. Linux Commands. SunOS Commands.
FreeBSD Commands. Full Man Repository. Returns a list of driver name and driver handle pairs for all drivers 'installed' loaded into the current process. The driver name does not include the 'DBD::' prefix.
For each load that succeeds the driver name and version number are added to a hash. When called in array context the list of successfully loaded drivers is returned without the 'DBD::' prefix. Due to the potentially high memory cost and unknown risks of loading in an unknown number of drivers that just happen to be installed on the system, this method is not recommended for general use.
Returns a list of data sources databases available via the named driver. The driver will be loaded if it hasn't been already. Note that many drivers have no way of knowing what data sources might be available for it. These drivers return an empty or incomplete list or may require driver-specific attributes. It can also be used to change where the trace output is sent. In addition to the DBI methods listed in the previous section, the DBI package also provides several utility functions.
These can be imported into your code by listing them in the use statement. Alternatively, all these utility functions except hash can be imported using the :utils import tag. Returns an informal description of the first character difference between the strings. Returns an informal description of the difference between two strings. Strings will be quoted, although internal quotes will not be escaped. Values known to be numeric will be unquoted. Undefined NULL values will be shown as undef without quotes.
If the string is flagged internally as utf8 then double quotes will be used, otherwise single quotes are used and unprintable characters will be replaced by dot. This function is designed to format values for human consumption.
It is used internally by the DBI for "trace" output. It should typically not be used for formatting values for database use. See also "quote". Returns true for each element that looks like a number. Returns false for each element that does not look like a number. Returns undef for each element that is undefined or empty. Both types are implemented in C and are very fast. This function doesn't have much to do with databases, except that it can sometimes be handy to store such values in a database.
It gives the perl scalar an 'integer aspect'. It gives the perl scalar a 'numeric aspect'. Technically the value gains an NV. If this flag is specified then when the driver successfully casts the bound perl scalar to a non-string type then the string portion of the scalar will be discarded.
Where an attribute is equivalent to a method call, then refer to the method call for all related documentation. Warning: these attributes are provided as a convenience but they do have limitations. Specifically, they have a short lifespan: because they are associated with the last handle used, they should only be used immediately after calling the method that "sets" them. If in any doubt, use the corresponding method call.
Please refer to the documentation for the "rows" method. Returns the native database engine error code from the last driver method called. The code is typically an integer but you should not assume that. Also, for most drivers, the statement handles share the same error variable as the parent database handle, so calling a method on one handle may reset the error on the related handles. If you need to test for specific error conditions and have your program be portable to different database engines, then you'll need to determine what the corresponding error codes are for all those engines and test for all of them.
Drivers should also do likewise. A driver may return 0 from err to indicate a warning condition after a method call. Similarly, a driver may return an empty string to indicate a 'success with information' condition.
In both these cases the value is false but not undef. The errstr and state methods may be used to retrieve extra information in these cases. Returns the native database engine error message from the last DBI method called. This has the same lifespan issues as the "err" method described above. The errstr method should not be used to test for errors, use err for that, because drivers may return 'success with information' or warning messages via errstr for methods that have not 'failed'.
Note that the specific success code is translated to any empty string false. The driver is free to return any value via state , e. The state method should not be used to test for errors, use err for that, because drivers may return a 'success with information' or warning state code via state for methods that have not 'failed'. Set the err , errstr , and state values for the handle. If the "HandleSetErr" attribute holds a reference to a subroutine it is called first.
See "HandleSetErr" for full details. Setting err to a true value indicates an error and will trigger the normal DBI error handling mechanisms, such as RaiseError and HandleError , if they are enabled, when execution returns from the DBI back to the application. Setting err to "" indicates an 'information' state, and setting it to "0" indicates a 'warning' state. Some special rules apply if the err or errstr values for the handle are already set The effect is that an 'information' state only overrides undef; a 'warning' overrides undef or 'information', and an 'error' state overrides anything.
The trace method is used to alter the trace settings for a handle and any future children of that handle. The func method can be used to call private non-standard and non-portable methods implemented by the driver.
Note that the function name is given as the last argument. This method is not directly related to calling stored procedures. Calling stored procedures is currently not defined by the DBI. Some drivers, such as DBD::Oracle, support it in non-portable ways. See driver documentation for more details. It returns false where a driver hasn't implemented a method and the default method is provided by the DBI's driver base class is just an empty stub.
Parses a string containing trace settings and returns the corresponding integer value used internally by the DBI and drivers. For example: "SQL 3 foo". Returns a reference to a hash whose keys are the names of driver-private handle attributes available for the kind of handle driver, database, statement that the method was called on. Brain transplants for handles. You don't need to know about this unless you want to become a handle surgeon.
A DBI handle is a reference to a tied hash. A tied hash has an inner hash that actually holds the contents. This is powerful stuff, expect problems. Use with care. Here's a quick kind of 'diagram' as a worked example to help think about what's happening:. Some attributes are inherited by child handles. That is, the value of an inherited attribute in a newly created statement handle is the same as the value in the parent database handle. Changes to attributes in the new statement handle do not affect the parent database handle and changes to the database handle do not affect existing statement handles, only future ones.
Attempting to set or get the value of an unknown attribute generates a warning, except for private driver specific attributes which all have names starting with a lowercase letter. The Warn attribute enables useful warnings for certain bad practices. It is enabled by default and should only be disabled in rare circumstances. The Active attribute is true if the handle object is "active". This is rarely used in applications. The exact meaning of active is somewhat vague at the moment.
The Executed attribute is true if the handle object has been "executed". When it's set on a handle it is also set on the parent handle at the same time. The Executed attribute for a database handle is cleared by the commit and rollback methods even if they fail. The Executed attribute of a statement handle is not cleared by the DBI under any circumstances and so acts as a permanent record of whether the statement handle was ever used.
For a driver handle, Kids is the number of currently existing database handles that were created from that driver handle. For a database handle, Kids is the number of currently existing statement handles that were created from that database handle.
For a statement handle, the value is zero. The Type attribute identifies the type of a DBI handle. Returns "dr" for driver handles, "db" for database handles and "st" for statement handles. The ChildHandles attribute contains a reference to an array of all the handles created by this handle which are still accessible.
The contents of the array are weak-refs and will become undef when the handle goes out of scope. They're cleared out occasionally. ChildHandles returns undef if your perl version does not support weak references check the Scalar::Util module. The referenced array returned should be treated as read-only. The CompatMode attribute is used by emulation layers such as Oraperl to enable compatible behaviour in the underlying driver e.
Not normally set by application code. It also has the effect of disabling the 'quick FETCH' of attribute values from the handles attribute cache. This makes them slightly slower but is useful for special-purpose drivers like DBD::Multiplex. The default value, false, means a handle will be fully destroyed as normal when the last reference to it is removed, just as you'd expect.
For a database handle, this attribute does not disable an explicit call to the disconnect method, only the implicit call from DESTROY that happens if the handle is still marked as Active. This attribute is specifically designed for use in Unix applications that "fork" child processes. For some drivers, when the child process exits the destruction of inherited handles cause the corresponding handles in the parent process to cease working. Either the parent or the child process, but not both, should set InactiveDestroy true on all their shared handles.
Alternatively, and preferably, the "AutoInactiveDestroy" can be set in the parent on connect. To help tracing applications using fork the process id is shown in the trace log whenever a DBI or handle trace method is called. The process id also shown for every method call if the DBI trace level not handle trace level is set high enough to show the trace from the DBI's method dispatcher, e. The "InactiveDestroy" attribute, described above, needs to be explicitly set in the child process after a fork , on every active database and statement handle.
This is a problem if the code that performs the fork is not under your control, perhaps in a third-party module. Use AutoInactiveDestroy to get around this situation.
It is strongly recommended that AutoInactiveDestroy is enabled on all new code it's only not enabled by default to avoid backwards compatibility problems. The PrintWarn attribute controls the printing of warnings recorded by the driver. When set to a true value the default the DBI will check method calls to see if a warning condition has been set. Fetching the full details of warnings can require an extra round-trip to the database server for some drivers.
In which case the driver may opt to only fetch the full details of warnings if the PrintWarn attribute is true. If PrintWarn is false then these drivers should still indicate the fact that there were warnings by setting the warning string to, for example: "3 warnings".
The PrintError attribute can be used to force errors to generate warnings using warn in addition to returning error codes in the normal way.
The RaiseWarn attribute can be used to force warnings to raise exceptions rather then simply printing them. It is "off" by default. If you turn RaiseWarn on then you'd normally turn PrintWarn off. If PrintWarn is also on, then the PrintWarn is done first naturally. The RaiseError attribute can be used to force errors to raise exceptions rather than simply return error codes in the normal way. If you turn RaiseError on then you'd normally turn PrintError off. If PrintError is also on, then the PrintError is done first naturally.
Typically RaiseError is used in conjunction with eval , or a module like Try::Tiny or TryCatch , to catch the exception that's been thrown and handle it. If you want to temporarily turn RaiseError off inside a library function that is likely to fail, for example , the recommended way is like this:.
The original value will automatically and reliably be restored by Perl, regardless of how the block is exited. The same logic applies to other attributes, including PrintError. The HandleError attribute can be used to provide your own alternative behaviour in case of errors. If set to a reference to a subroutine then that subroutine is called when an error is detected at the same point that RaiseError and PrintError are handled. It is called also when RaiseWarn is enabled and a warning is detected.
The subroutine is called with three parameters: the error message string that RaiseError , RaiseWarn or PrintError would use, the DBI handle being used, and the first value being returned by the method that failed typically undef.
Using a my inside a subroutine to store the previous HandleError value is important. See perlsub and perlref for more information about closures.
This example appends a stack trace to all errors and, unlike the previous example using Carp::confess, this will work PrintError as well as RaiseError :. This only works for methods which return a single value and is hard to make reliable avoiding infinite loops, for example and so isn't recommended for general use!
If you find a good use for it then please let me know. The HandleSetErr attribute can be used to intercept the setting of handle err , errstr , and state values. It is possible to 'stack' multiple HandleSetErr handlers by using closures. See "HandleError" for an example. HandleError is only invoked at the point where the DBI is about to return to the application with err set true.
It's not invoked by the failure of a method that's been called by another DBI method. So it's not just for errors, despite the name, but also warn and info states. This isn't excepted to be common and any such cases should be clearly marked in the driver documentation and discussed on the dbi-dev mailing list. It isn't incremented by warnings or information states.
It is not reset by the DBI at any time. The exact format of the appended text is subject to change. The TraceLevel attribute can be used as an alternative to the "trace" method to set the DBI trace level and trace flags for a specific handle. The TraceLevel attribute is especially useful combined with local to alter the trace settings for just a single block of code. It can only be set for driver and database handles. For statement handles the value is frozen when prepare is called.
The ChopBlanks attribute can be used to control the trimming of trailing space characters from fixed width character CHAR fields. No other field types are affected, even where field values have trailing spaces.
The default is false although it is possible that the default may change. Applications that need specific behaviour should set the attribute as needed. Drivers are not required to support this attribute, but any driver which does not support it must arrange to return undef as the attribute value. The LongReadLen attribute only relates to fetching and reading long values; it is not involved in inserting or updating them. A value of 0 means not to automatically fetch any long data.
Drivers may return undef or an empty string for long fields when LongReadLen is 0. The default is typically 0 zero or 80 bytes but may vary between drivers. Applications fetching long fields should set this value to slightly larger than the longest long field value to be fetched. Some databases return some long types encoded as pairs of hex digits.
For these types, LongReadLen relates to the underlying data length and not the doubled-up length of the encoded string. For most drivers the value used here has a direct effect on the memory used by the statement handle while it's active, so don't be too generous. If you can't be sure what value to use you could execute an extra select statement to determine the longest value.
You may need to take extra care if the table can be modified between the first select and the second being executed. See also "LongTruncOk" for information on truncation of long types. The LongTruncOk attribute may be used to control the effect of fetching a long field value which has been truncated typically because it's longer than the value of the LongReadLen attribute. By default, LongTruncOk is false and so fetching a long value that needs to be truncated will cause the fetch to fail.
Applications should always be sure to check for errors after a fetch loop in case an error, such as a divide by zero or long field truncation, caused the fetch to terminate prematurely. If a fetch fails due to a long field truncation when LongTruncOk is false, many drivers will allow you to continue fetching further rows. If the TaintIn attribute is set to a true value and Perl is running in taint mode e. This may change.
The attribute defaults to off, even if Perl is in taint mode. See perlsec for more about taint mode. If Perl is not running in taint mode, this attribute has no effect. When fetching data that you trust you can turn off the TaintIn attribute, for that statement handle, for the duration of the fetch loop. If the TaintOut attribute is set to a true value and Perl is running in taint mode e. When fetching data that you trust you can turn off the TaintOut attribute, for that statement handle, for the duration of the fetch loop.
Currently only fetched data is tainted. It is possible that the results of other DBI method calls, and the value of fetched attributes, may also be tainted in future versions. That change may well break your applications unless you take great care now.
If you use DBI Taint mode, please report your experience and any suggestions for changes. The Taint attribute is a shortcut for "TaintIn" and "TaintOut" it is also present for backwards compatibility. Setting this attribute sets both "TaintIn" and "TaintOut" , and retrieving it returns a true value if and only if "TaintIn" and "TaintOut" are both set to true values. The Profile attribute enables the collection and reporting of method call timing statistics.
See the DBI::Profile module documentation for much more detail. An application can set the ReadOnly attribute of a handle to a true value to indicate that it will not be attempting to make any changes using that handle or any children of it.
Note that the exact definition of 'read only' is rather fuzzy. For more details see the documentation for the driver you're using. If the driver can make the handle truly read-only then it should unless doing so would have unpleasant side effect, like changing the consistency level from per-statement to per-session.
Otherwise the attribute is simply advisory. A driver can set the ReadOnly attribute itself to indicate that the data it is connected to cannot be changed for some reason.
If the driver cannot ensure the ReadOnly attribute is adhered to it will record a warning. In this case reading the ReadOnly attribute back after it is set true will return true even if the underlying driver cannot ensure this so any application knows the application declared itself ReadOnly. Library modules and proxy drivers can use the attribute to influence their behavior.
For example, the DBD::Gofer driver considers the ReadOnly attribute when making a decision about whether to retry an operation that failed. At the extreme, it lets you become a puppet master, deceiving the application in any way you want.
The Callbacks attribute is a hash reference where the keys are DBI method names and the values are code references. For each key naming a method, the DBI will execute the associated code reference before executing the method. The arguments to the code reference will be the same as to the method, including the invocant a database handle or statement handle.
For example, say that to callback to some code on a call to prepare :. Because callbacks are executed before the methods they're associated with, you can modify the arguments before they're passed on to the method call. In this case we've created the attributes hash if it's not passed to the prepare call. You can also prevent the associated method from ever executing.
This allows multiple callbacks to share the same code reference and still know what method was called. For example, if you wanted to disable calls to ping , you could do this:. As with other attributes, Callbacks can be specified on a handle or via the attributes to connect. Callbacks can also be applied to a statement methods on a statement handle.
The Callbacks attribute of a database handle isn't copied to any statement handles it creates. So setting callbacks for a statement handle requires you to set the Callbacks attribute on the statement handle yourself, as in the example above, or use the special ChildCallbacks key described below. In addition to DBI handle method names, the Callbacks hash reference supports four additional keys.
The first is the ChildCallbacks key. When a statement handle is created from a database handle the ChildCallbacks key of the database handle's Callbacks attribute, if any, becomes the new Callbacks attribute of the statement handle. This allows you to define callbacks for all statement handles created from a database handle. For example, if you wanted to count how many times execute was called in your application, you could write:. Here we'll describe an alternative approach using a callback.
The upshot is that new database handles are created with AutoCommit enabled, while cached database handles are left in whatever transaction state they happened to be in when retrieved from the cache. Note that we've also used a lexical for the callbacks hash reference. Which would rather defeat the purpose. The connected method is a no-op by default unless you subclass the DBI and change it. The DBI calls it to indicate that a new connection has been made and the connection attributes have all been set.
You can give it a bit of added functionality by applying a callback to it. This is because connected is called for both new and reused database handles, but you want to execute a callback only the when a new database handle is returned.
For example, to set the time zone on connection to a PostgreSQL database, try this:. One significant limitation with callbacks is that there can only be one per method per handle.
This means it's easy for one use of callbacks to interfere with, or typically simply overwrite, another use of callbacks. For this reason modules using callbacks should document the fact clearly so application authors can tell if use of callbacks by the module will clash with use of callbacks by the application.
You might be able to work around this issue by taking a copy of the original callback and calling it within your own. It is strongly recommended that you use just one private attribute e. This attribute is primarily of interest to people sub-classing DBI, or for applications to piggy-back extra information onto DBI handles. Effectively the same as doing:. This behaviour is unreliable and so use of clone without an argument is deprecated and may cause a warning in a future release. Prepare and execute a single statement.
Returns the number of rows affected or undef on error. A return value of -1 means the number of rows is not known, not applicable, or not available. This method is typically most useful for non - SELECT statements that either cannot be prepared in advance due to a limitation of the driver or do not need to be executed repeatedly. It should not be used for SELECT statements because it does not return a statement handle so you can't fetch any data.
But if you'll be executing the statement many times then it's more efficient to prepare it once and call execute many times instead. Note drivers are free to avoid the overhead of creating an DBI statement handle for do , especially if there are no parameters. In this case error handlers, if invoked during do , will be passed the database handle. Returns a value 'identifying' the row just inserted, if possible. Returns undef if the driver does not support the method or can't determine the value.
If you don't know the parameter values and your driver does not need them, then use undef for each. There are several caveats to be aware of with this method if you want to use it for portable applications:. In this case the value returned would be from the last non-placeholder insert statement. For example, being told the name of the database 'sequence' object that holds the value. Drivers using any approach like this should issue a warning if AutoCommit is true because it is generally unsafe - another process may have modified the table between your insert and the select.
If called in a list context, it returns the first row of data from the statement. If called in a scalar context for a statement handle that has more than one column, it is undefined whether the driver will return the value of the first column or the last. So don't do that. Also, in a scalar context, an undef is returned if there are no more rows or if an error occurred.
That undef can't be distinguished from an undef returned because the first field value was NULL. It returns the first row of data from the statement. It returns a reference to an array containing a reference to an array or hash, see below for each row of data fetched. This is recommended if the statement is going to be executed many times.
The only difference between the two is that if Slice is not defined and Columns is an array ref, then the array is assumed to contain column index values which count from 1 , rather than perl array index values. You may often want to fetch an array of rows where each row is stored as a hash. That can be done simply using:. Note that if "RaiseError" is not set then you can't tell the difference between returning no rows and an error.
Using RaiseError is best practice. It can either be the name of a single field, or a reference to an array containing multiple field names. Using multiple names yields a tree of nested hashes. This utility method combines "prepare" , "execute" , and fetching one column from all the rows, into a single call. It returns a reference to an array containing the values of the first column from each row.
If fetch fails and "RaiseError" is not set, then it will return with whatever data it has fetched thus far. However, it can also push another column, or even multiple columns per row, into the result array.
This behaviour can be specified via a ' Columns ' attribute which must be a ref to an array containing the column number or numbers to use.
Prepares a statement for later execution by the database engine and returns a reference to a statement handle object. The returned statement handle can be used to get attributes of the statement and invoke the "execute" method. See "Statement Handle Methods". Portable applications should take this into account. In general, DBI drivers do not parse the contents of the statement other than simply counting any Placeholders. The statement is passed directly to the database engine, sometimes known as pass-thru mode.
This has advantages and disadvantages. On the plus side, you can access all the functionality of the engine being used. On the downside, you're limited if you're using a simple engine, and you need to take extra care if writing applications intended to be portable between engines. Some command-line SQL tools use statement terminators, like a semicolon, to indicate the end of a statement. Such terminators should not normally be used with the DBI.
Be sure to understand the cautions and caveats noted below. There are several alternatives:. Caveat emptor: This caching can be useful in some applications, but it can also cause problems and should be used with care. Here is a contrived case where caching would cause a significant problem:. The results will certainly not be what you expect. Also, to ensure the attributes passed are always the same, avoid passing references inline. For example, the Slice attribute is specified as a reference.
If you'd like the cache to managed intelligently, you can tie the hashref returned by CachedKids to an appropriate caching module, such as Tie::Cache::LRU :. Commit make permanent the most recent series of database changes if the database supports transactions and AutoCommit is off. If AutoCommit is on, then calling commit will issue a "commit ineffective with AutoCommit" warning.
Rollback undo the most recent series of uncommitted database changes if the database supports transactions and AutoCommit is off. If AutoCommit is on, then calling rollback will issue a "rollback ineffective with AutoCommit" warning. Enable transactions by turning AutoCommit off until the next call to commit or rollback. After the next commit or rollback , AutoCommit will automatically be turned on again. Disconnects the database from the database handle. The handle is of little use after disconnecting.
The transaction behaviour of the disconnect method is, sadly, undefined. Some database systems such as Oracle and Ingres will automatically commit any outstanding changes, but others such as Informix will rollback any outstanding changes. Applications not using AutoCommit should explicitly call commit or rollback before calling disconnect. The database is automatically disconnected by the DESTROY method if still connected when there are no longer any references to the handle.
Also, do not rely on the order of object destruction during "global destruction", as it is undefined. Generally, if you want your changes to be committed or rolled back when you disconnect, then you should explicitly call "commit" or "rollback" before disconnecting. If you disconnect from a database while you still have active statement handles e. The warning may indicate that a fetch loop terminated early, perhaps due to an uncaught error.
To avoid the warning call the finish method on the active handles. Attempts to determine, in a reasonably efficient way, if the database server is still running and the connection to it is still working.
Individual drivers should implement this function in the most suitable manner for their database engine. The current default implementation always returns true without actually doing anything. Actually, it returns " 0 but true " which is true but zero. That way you can tell if the return value is genuine or just the default.
Drivers should override this method with one that does the right thing for their type of database. Few applications would have direct use for this method. See the specialized Apache::DBI module for one example usage. Returns information about the implementation, i.
It returns undef for unknown or unimplemented information types. See "Standards Reference Information" for more detailed information about the information types and their meanings and possible return values. Values in that range which have been assigned a meaning are defined here:. The backslash will be removed before the text is passed to the backend.
Returns an active statement handle that can be used to fetch information about tables and views that exist in the database. Each value may optionally be quoted, e. If your driver doesn't support one or more of the selection filter parameters then you may get back more than you asked for and can do the filtering yourself. This method can be expensive, and can return a large amount of data. For example, small Oracle installation returns over rows.
The following script let you test if your installation is working fine:! Again, at the ppm prompt type search Data-Table and when found type install Data-Table, as shown here. These instructions refer to downloading and installing the DBD module for MySQL, but you can install more than one of the modules to access different types of database software. The same Perl commands wich work for one database type will work for the other types: the code is portable not only across platforms, but also across database software.
Once more, at the ppm prompt type search DBD and see the variety of modules available. You are only interested in installing the driver for Mysql and at the ppm prompt type install DBD-Mysql and this is it.
0コメント