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
  SetLength(List,count)
  iPos:=1;
  for iLcv=0 to Count-1 do begin
    System.Move(String[iPos],List[iLcv],8);
    Inc(iPos,8);
  end;
end;
function toBlob(List):string;
begin
  iLen=System.Length(List)*8;
  System.SetLength(Result,iLen);
  iPos:=1;
  for iLcv:=0 to High(List) do begin
    System.Move(List[iLcv],Result[iPos],8);
    Inc(iPos,8);
  end;
end;

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 to work
Retrieving converting the list (asString) from teh database with larger values no longer works.

Did anyone do anything to System.Move?
Did anyone recently do work on BLOB features to MySQL 5.1 connector?

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 TMemoField and BLOB (binary LOB) to TBlobField
but I do not think, that this can cause your problems. L.

Well, I did some recursive tests and there is nothing wrong with Move or the Int64Array and supporting methods using the latest FPC/Lazarus. AND this issue is not a problem with PostgreSQL 9.1 - so at least I'm able to continue working...

This is a problem with MySQL 5.1 and blobs - I'm surprised this isn't more noticeable with other blob entries.

my app maps this particular field as SQL_LONGVARBINARY

Query.Params.ParamByName(sName).AsBlob:=uInt64Array.toBlob(Value);

And which SQL DBConnector do you use ?
TMySQL51Connection ?

my app maps this particular field as SQL_LONGVARBINARY

or TODBCConnection ?

L.

What is "large". Remember that the upper limit for blobs sent in a sql statement is max_allowed_packet. Default is 1M.

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_m ax_allowed_packet

To send larger blobs you need to prepare the statement and send data in chuncks. Not supported in sqldb.

Ludo

23.09.2011 5:52, Andrew Brunner пишет:

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 types like (dynamic) array of byte.

Regards,
Sergei

So TBlobField.Value probably should be changed to array of byte and there should be a TField.AsByteArray property?

Martin

LacaK wrote

TMySQL51Connection ?

I'm using TMySQL51Connection.

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 types like (dynamic) array of byte.

I always felt uncomfortable with converting binary types to strings because I know older strings with #0 would cause memory leaks. I think this has something to do with the problem.

I think blobs should be stream objects so we can write/read that way.

Yes, Certainly. Or better even Stream objects.

String index is one-based, array of byte index is null-based and has no copy on write semantic, a TStream is not refcounted and must be destroyed in code if copied by TBlobField or is invalid if the TField instance is destroyed if not copied by TBlobField. Programs can not handle String, array of byte or TStream in the same way.

Martin

Why not use (or introduce) an TBlob type, matching the need of DB users and other users, which currently use strings for storing raw bytes. It must not be a really new type, just an alias for the suggested type for such content.

DoDi

Martin Schreiber wrote / napísal(a):

It seems, that Delphi XE does it in this way:
Value is of type TBlob and TBlob is byte array
http://docwiki.embarcadero.com/VCL/en/DB.TBlobField.Value

and there should be a TField.AsByteArray property?

Better use compatible "AsBytes":
http://docwiki.embarcadero.com/VCL/en/DB.TField.AsBytes http://docwiki.embarcadero.com/VCL/en/DB.TBlobField.GetAsBytes

-Laco.