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 RawByte
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, match
Andrew Brunner schrieb:
On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber 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 hand
On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber 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 non-string
On Fri, Sep 23, 2011 at 7:00 AM, 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 t
On Fri, Sep 23, 2011 at 1:07 AM, LacaK wrote:
> TMySQL51Connection ?
I'm using TMySQL51Connection.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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-st
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
>
>
> 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
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
http://lists.freepascal.org/mailman/listinfo/fpc
On Fri, Sep 23, 2011 at 12:12 AM, LacaK 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=17417&r2=18951
> which introduced mappi
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=17417&r2=18951
which introduced mapping from MySQL TEXT datatype (character LOB) to
TMemoFiel
12 matches
Mail list logo
