Re: Persistent fields - ADO - Oracle database
- From: "Arnie" <none>
- Date: Tue, 28 Feb 2006 12:46:59 -0500
"Mick Board" <mick_board@xxxxxxxxx> wrote in message
news:4403f32a@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi,
We have a client/server application written in Delphi 7 which
uses ADO to connect to Oracle and SQL Server databases.
A client site has been having trouble with their Oracle version
being unstable in Oracle 9.2.0.1. Oracle advised them to move
to 9.2.0.7 to attempt to resolve their problem. It's a
Solaris Unix site.
However, on attempting to run our .exe, after upgrading the
database, a new bug has been introduced with Delphi. The
database has a field which is NUMBER(1) in size. With Oracle
8i (my development environment), the persistent field was
created as a TFloatField. However, an error message is now
being displayed in the Oracle 9.2.0.7 environment "Type
mismatch for field '{field name}', expecting: Float actual:
Integer.
Now, looking at the field I guess I can see why it would like
it to be an Integer. This has always run fine before on Oracle
8i, 9.2.0.1 here and 9.2.0.1 at site. It also works with SQL
Server. I guess I can always code something to get around this
(somehow), but I'm a bit concerned that this initial error
could be the type of the iceberg (so to speak).
Has anyone experienced this before? (i.e. differences between
Oracle versions?)
I'd be pleased if anyone could shed some light on this
situation.
Kind Regards,
Mick Board
Hi Mick,
FWIW, this may have nothing to do with your problem.
Oracle normally treats all NUMBER(n) columns as floats. We have
NUMBER(1) columns, but none are persistent fields. We haven't
had to change anything for Oracle 8, 9 or 10. They could
probably just as well be CHAR(1) fields because most are used for
flags.
We do use NUMBER(5) and NUMBER(10) persistent fields with our
client (forms) apps. When creating one of these fields against
an Oracle DB, it will be created as a TFloatField. Then, we had
problems when going against SQL Server or DB2, where the
equivalent columns are defined as INTEGER; an error similar to
yours.
I put together code that dynamically changes the persistent field
type to either integer or smallint, as required, at runtime when
the DB isn't Oracle.
Sorry if this isn't your problem.
- Arnie
.
- References:
- Persistent fields - ADO - Oracle database
- From: Mick Board
- Persistent fields - ADO - Oracle database
- Prev by Date: Re: Help on resolving record conflicts with ADO
- Previous by thread: Persistent fields - ADO - Oracle database
- Index(es):
Relevant Pages
|
