Is the bind_param command working correctly in that you cannot change the
ora_type value after it is initially set?

When using the bind_param statement, DBI is caching the ora_type value
against each bind parameter.  If you subsequently try to issue another
bind_param statement against the same bind parameter then explicitly setting
the ora_type value has no effect.

For instance

$csr->bind_param(1, "value 1");
$csr->bind_param(1, "value 2", { ora_type => ORA_CHAR });       # Explicitly
setting the ora_type value here has no effect
                                                                # and it is
already set to the default value ORA_VARCHAR2

I am trying to explicitly set the ora_type value after it is initially set,
as a workaround for a problem where ora_type set to VARCHAR2 (default)
strips off trailing spaces.  Whenever I want to insert a space into a "NOT
NULL" field, I explicitly set the ora_type value to ORA_CHAR to prevent
trailing spaces from being removed.  However, if the bind parameter ora_type
has already been set to ORA_VARCHAR2, I cannot change it and the insert
fails.

I can get around the problem by always setting every bind_param ora_type
value to be ORA_CHAR for every "NOT NULL" column that potentially can have a
space inserted into it.

I cannot think of any other reason why you should need to change the bind
parameter ora_type value after it is initially set, other than to fix the
problem of inserting spaces into "NOT NULL" fields.  However, should it
always be possible to force it to change after it has been initially set by
using another call to the bind_param function?

I'm using DBI-1.35 with DBD::Oracle-1.14



This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management and
security reasons. This access is controlled under Regulation of
Investigatory Powers Act 2000, Lawful Business Practises.

Reply via email to