Martin Schreiber wrote / napísal(a):
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote:
Recently strings behavior was changed, they are now codepage-aware. The
compiler can now implicitly convert strings from one encoding to another.
To handle non-string data, you should use
On Fri, Sep 23, 2011 at 12:12 AM, LacaK la...@zoznam.sk wrote:
Did anyone recently do work on BLOB features to MySQL 5.1 connector?
there was commited only this
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/sqldb/mysql/mysqlconn.inc?r1=17417r2=18951
which introduced
And which SQL DBConnector do you use ?
TMySQL51Connection ?
my app maps this particular field as SQL_LONGVARBINARY
or TODBCConnection ?
L.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
I use latest FPC from /trunk/ and this problem just started
happening recently.
Pseudo code
Write To SQL as Blob (using parameter binding)
Param.AsString=uInt64Array.toBlob(MyList);
unit uInt64Array
procedure fromBlob(List,string)
count=length(string) div 8; // size of
23.09.2011 5:52, Andrew Brunner пишет:
I use latest FPC from /trunk/ and this problem just started happening recently.
...
Posting to the MySQL 5.1 database : the field size is as expected.
Retrieving /converting the list (asString) from the database with all
values set to small numbers appears
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote:
Recently strings behavior was changed, they are now codepage-aware. The
compiler can now implicitly convert strings from one encoding to another.
To handle non-string data, you should use RawByteString type, or better
yet non-string
On Fri, Sep 23, 2011 at 1:07 AM, LacaK la...@zoznam.sk wrote:
TMySQL51Connection ?
I'm using TMySQL51Connection.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Fri, Sep 23, 2011 at 7:00 AM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:
Recently strings behavior was changed, they are now codepage-aware. The
compiler can now implicitly convert strings from one encoding to another. To
handle non-string data, you should use RawByteString type, or
On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber mse00...@gmail.com wrote:
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote:
Recently strings behavior was changed, they are now codepage-aware. The
compiler can now implicitly convert strings from one encoding to another.
To handle
Andrew Brunner schrieb:
On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber mse00...@gmail.com wrote:
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote:
Recently strings behavior was changed, they are now codepage-aware. The
compiler can now implicitly convert strings from one encoding
On Friday 23 September 2011 16.32:21 Hans-Peter Diettrich wrote:
So TBlobField.Value probably should be changed to array of byte and
there should be a TField.AsByteArray property?
Yes, Certainly. Or better even Stream objects.
Why not use (or introduce) an TBlob type, matching the
Did anyone recently do work on BLOB features to MySQL 5.1 connector?
there was commited only this
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/sqldb/mysql/mysqlconn.inc?r1=17417r2=18951
which introduced mapping from MySQL TEXT datatype (character LOB) to
12 matches
Mail list logo