Arí Ricardo Ody wrote:
First, thaks to everyone that post msgs trying to answer my questions.
I have a weak skill in Lazarus/Pascal if compared with people like you. I can't
understand why you don't solve the trouble instead of try to send the correct
msg error.
As John suggested, I don't have a DB2 database running here, so we need you to
run some more tests.
I understand that this can require some skills that you don't have yet. So how
to acquire them?
Step 1 would of course be the Wiki. Unfortunately their are two Wiki's at the
moment -- one for Lazarus and one for FPC. You should try searching both.
Also, searching the mailing list archives or Googling around can help you out.
Note: the mailing list archives are on the Lazarus website, but if you keep all
messages from the mailing list you received, you can even build up a local
archive. Searching a local archive can be done using e.g. your mail program.
Searching the archives on the website can be done using Google. Looking at the
url of the archives, you can see it starts with
http://www.lazarus.freepascal.org/list_archives/lazarus/. So you can use the
'site:' parameter in a Google query e.g. as follows: 'apply patch
site:http://www.lazarus.freepascal.org/list_archives/lazarus'.
The Lazarus Wiki gives some nice hits on the simple query 'Patch'. Just try it!
You'll quickly find
http://wiki.lazarus.freepascal.org/index.php/Creating_A_Patch. This page also
links you to the
http://wiki.lazarus.freepascal.org/index.php/Getting_Lazarus#Via_SVN page,
explaining you how to get the Lazarus sources via SVN. How to get the FPC
sources (which you'd need in this case), is explained on the FPC website, under
'Development' (http://www.freepascal.org/develop.html).
But perhaps you still don't have a clue about what to do. So you post a message
on the mailing list! Then people can even give you additional hints. Of course
you'd have to explain what exactly is causing you trouble, e.g. 'I don't know
what SVN is' or 'I don't know how to apply a patch to my checked out FPC
sources'.
In this case: I know of two ways to test a patch:
1) apply the patch to a local copy of the source, e.g. the source checked out
from SVN, apply the patch to it, compile FPC from these sources (using the
simple command 'make') and test it
2) apply the patch to a local copy of the source, or at least to the files
concerned, copy the required files to your project directory, and compile them
there with your project
I already hinted this in my message with the patch attached.
Details on checking out the sources from SVN are on the web pages mentioned
above.
A little note on option 2: you need to copy enough source files to guarantee
that you program will use the local copied (patched) files. In this case it
means you not only have to copy the two patched files -- odbcconn.pas and
odbcsql.inc, but also the odbcsqldyn.pp file, since odbcconn has the odbcsqldyn
unit in its uses clause, which in turn includes the odbcsql.inc file.
A second note on option 2: this is an option of the type 'temporary hack'. Use
it with caution. As said in my previous mail, be aware that having the units in
your local project directory will prevent your program from using newer
versions of the units (if any) when using a newer FPC at some point of time in
the future.
Third note: option 2 is applied most effectively on units that are 'leaves' in
the (imagined) 'dependency tree' of the FPC units. E.g. it doesn't work very
well with the classes unit in a program using many units that use the classes
unit on their own. Also, it does not work for patches to the compiler itself of
course.
I used option 2 when creating & testing the patch.
I would like to give you a suggestion. Here we go:
In COBOL(I bag your pardon) each column name/type of a DB2 table has a host
variable(as cobol people call it) associated. In the case of TIMESTAMP, the
associated variable will be declared:
03 <column-name> PIC X(26).
(column HREG_DIVDD TIMESTAMP will generate a cobol variable 03 HREG-DIVDD PIC
X(26).)
The content of this host will come in the format: YYYY-MM-DD HH.MM.SS.UUUUUU ->
where UUUUUU represents fractions of second. If you see, this format use 26 bytes
in length. Programmers then, code the cobol statements necessary to compare the
returned value with other variables of mount a value that will be put in the DB2
TABLE via a EXEC SQL INSERT or EXEC SQL UPDATE.
Why, instead off try to return the wrong error, you don't try to return the value of the
TIMESTAMP as "string [26]" format. If you're interested I can send you a list
of the DB2 tables and the format that cobol program receive them and a brief explanation
of how you interpert these formats received.
(I have never programmed in COBOL.) As Michael just mailed, what is really
important here, is to what ODBC data type the DB2 ODBC driver maps the
TIMESTAMP type. Thanks for your try anyway!
I can request ODBC to convert every field to a string (though an ODBC driver
might perhaps fail to do this for all data types), but of course it would make
much more sense if a TIMESTAMP were converted to a TDateTime in this case.
Regards,
Bram
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
