[Gambas-user] Problem with MySQL LONGTEXT field type

Luigi Carlotto md9327 at ...120...
Sun Dec 14 13:05:35 CET 2008


Gambas2 - versione 2.9.0

The single anomaly verification in a circumstance, that I will try to
describe:

- I have created a small static class that executes the logon to a
database, executes query and returns the data in a structure much
similar one to the logic applied to the Result/Field objects; at last
the logon comes sluice.  This my logic is created in order to avoid to
leave the logon open and, since the Result object maintains the data
single to opened logon, my class copy these data in an appropriate
structure of Array of objects, that it comes returned to the procedures
that use this function.
- the calling procedures use this class, that the structure returns
given, that comes used for determined scopes.
- the logons can be made on database PostgreSQL, MySQL and SQLite; the
query they come correctly executed, returning the corrected values,
unless for MySQL. Like described in the first mail, one of the query
executes a loading of information from a table of system of MySQL, used
in order to determine the structure of the database.
- some fields of this table are of type “longtext” (BLOB).
- Strangely, these fields return a value NULL, although their content is
instead a valid data.
- Verifying the Result object, immediately after the execution of the
query, I have found that the value of this field is truly NULL, and this
excludes an anomaly of my procedures.
- To ulterior I have had confirmation, constructing it a small procedure
of test, in which it executes the same operations made from my program,
and that it uses the same static class; strangely, the query executed
from the test program, it has given back a valid value in the field
“longtest”.
- The thing has made me to rise a doubt: since my program is rather
complex, he is probable exists some problem in memory (stack) with the
management of fields BLOB?
- Knowing enough language C/C++, I have given to a glance to the code
source of the library, but the only thing that I have found is that
fields BLOB come managed in way detail, but has not found details
conditions that could make me to doubt on they a wrong management.  The
only thing that has come to me in mind, is perhaps that a problem of
memory with programs exists many complexes, for which this type of data
(blob) comes lost…
- I have found this single anomaly in MySQL, but it is also true that
the others dbms do not use this type of data (blob) in the system
tables.

Some suggestion?

Thanks



More information about the User mailing list