Arí Ricardo Ody wrote:
At 14:03 4/4/2006, you wrote:
That's because UpdateIndexDefs isn't defined.
It remains being a mistery for me. Since RDBMS is who manage index(es)
and key(s)...
In order to construct sensible WHERE clauses of UPDATE and DELETE statements,
SQLDB needs to know which column is the primary key. SQLDB does not manage the
keys of course.
Example:
myTable has primary key id
SELECT * FROM myTable
now I make changes to the record with id=34578
SQLDB finds out that id is the primary key and does:
UPDATE mtTable SET .... WHERE id=34578
how else would it know that it should use the id field in the WHERE clause?
You see?
The format is supported by IBM in lots of machines of various
capacities... Thousands? Who is the most important: Be a pig-headed or
prepare a tool that can be used by thousands of programmers around the
world?
We already saw that:
- you could try casting the field in the SQL statement (but then you will need
to do some manual stuff instead of only linking come DB* components)
- you could try making the field definition (TFieldDef) for the TIMESTAMP
column having type a FieldType of stString and setting the Size to 26
- you/we could try to make a TTimeStamp with supports a Precision property (or
just a TNanoTimeStamp etc.) (this makes only sense if the DB2 ODBC also
actually passes the precision)
- Delphi does not give you more than 3 digits accuracy for the seconds in the
timestamp
- MS Access has only 3 digits accuracy
- MySQL has 0 digits accuracy
I think this gives enough motivation why currently 6-digit precision is not
supported. When we (I) have time, I will try to expand the possibilities of
ODBCConn to deal with these timestamps -- if it's possible at all -- but it
just isn't a very high priority. Meanwhile, you can also try to experiment with
the suggested workarounds.
Regards,
Bram
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives