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
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 int64
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
13 matches
Mail list logo
