Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: Delphi-BCB/Database/TField/TStringField    [ Add a report in this area ]  
Report #:  72449   Status: Closed
DB.TStringField.Value should be a normal Unicode string, but is an AnsiString
Project:  Delphi Build #:  12.0.3210.17555
Version:    12.1 Submitted By:   Roger Dunn
Report Type:  Minor failure / Design problem Date Reported:  3/24/2009 9:14:35 AM
Severity:    Commonly encountered problem Last Updated: 3/31/2009 12:52:23 PM
Platform:    All platforms Internal Tracking #:  
Resolution: As Designed (Resolution Comments) Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: No Ratings Yet
0.00 out of 5
Total Votes: None
Description
In DB.pas, TStringField's Value property field SHOULD be defined as a String or UnicodeString but is defined as an AnsiString instead.  I get all these warnings compiling my project when I use TStringField.Value in a ShowMessage, write it to a file, or compare it with other strings.  Only the AsString property employs UnicodeString.  Is this a bug?  And if not, why isn't Value a UnicodeString?  Should I change all this code to use AsString instead of Value?
Steps to Reproduce:
None
Workarounds
None
Attachment
None
Comments

Tomohiro Takahashi at 3/26/2009 12:35:03 AM -
Which RDBMS are you using?
Which database connectivity are you using, BDE, dbExpress, IBExpress, ADO etc...?
If you handle Unicode database, please try to use TWideStringField instead of TStringField.

Roger Dunn at 3/31/2009 11:48:48 AM -
I am using BDE.  But I thought all the databases used the DB unit, since it's generic.  When I import fields from my database, they become TStringFields automatically.

Mark Edington (Embarcadero) at 3/31/2009 12:53:19 PM -
In each of the various TField classes, the "Value" property is defined based on the associated data type.   TField descendents redefine this property when the associated data type changes from the definition in ancestor class.

TStringField has always been used to access data stored in single byte formats.  The data type associated with TStringField is, and always has been, AnsiString.  In releases of the product prior to Delphi 2009 the association was implicit by the fact that string=AnsiString and TStringField.Value=string.  Because the definition of string type changed in Delphi 2009, the declaration of TStringField.Value had to change to AnsiString to maintain the correct type association.

None of the other AsXXX properties defined on TField change in descendent field types.    Since AsString is not tied to a single TField data type, there is no reason why it could not "float" along with "string" from AnsiString to UnicodeString.   In fact, this is the most obvious choice since most existing code that reads or writes from the AsString property is very likely using another "string" type.   Using "string" for the type also allows code to be compiled with both Delphi 2009 and previous releases without warnings.  If TField.AsString had instead been redefined to return an AnsiString then all existing code that writes to the AsString property using a string type would generate "potential data loss" warnings for the implicit conversion from Unicode to Ansi.

For migration, existing code that has dependencies on the single byte characters and directly manipulates the payload of TStringField should use AnsiString variables and read/write the field data using the TStringField.Value property.   Code which has no dependency on the size of the character data and just needs to deal with an opaque string value should use the TField.AsString or TField.Text properties instead.

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.