Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-26 Thread LacaK 

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 RawByteString type, or better
yet non-string types like (dynamic) array of byte.



So TBlobField.Value probably should be changed to array of byte

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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Andrew Brunner 
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 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);
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread LacaK 

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-devel

RE : [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Ludo Brands 
 
 
 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? 

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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Sergei Gorelkin 

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 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?


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


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Martin Schreiber 
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 types like (dynamic) array of byte.
 
So TBlobField.Value probably should be changed to array of byte and there 
should be a TField.AsByteArray property?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Andrew Brunner 
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

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Andrew Brunner 
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 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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Andrew Brunner 
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 non-string data, you should use RawByteString type, or better
 yet non-string types like (dynamic) array of byte.

 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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Hans-Peter Diettrich 

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 to another.
To handle non-string data, you should use RawByteString type, or better
yet non-string types like (dynamic) array of byte.


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 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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-23 Thread Martin Schreiber 
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 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.
 
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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Major problem with Move and Array of Int64

2011-09-22 Thread Andrew Brunner 
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?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Major problem with Move and Array of Int64

2011-09-22 Thread LacaK 



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 
TMemoField and BLOB (binary LOB) to TBlobField

but I do not think, that this can cause your problems.
L.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel