RE: Update on Your Request {40293}

Steve Farmer

9 years ago
updated 8 years ago
Completed

Hi Sergey,

I spend quite a lot of time on databases that I haven't written or designed,
these often have errors within them when FireDAC looks at them. I have in
the past exported the data to a new file and corrected the errors, or I have
written a quick application to truncate the data, however as the data is
usually unimportant, I just want to create the query, then to ignore field
length errors would not be a problem to me.

Ideal would be to have an option to "Truncate field length errors" . or to
have a hidden switch in the INI File if you think that this would be a
problem to others ?

Best Regards

Steve

From: ActiveDBSoft Support Team [mailto:customer-service@activedbsoft.com]
Sent: 08 December 2015 04:44
To: steve.farmer@elginhill.com
Subject: RE: Update on Your Request {40293}

Request Update

View the complete request history
<http://www.activedbsoft.com/helpdesk/index.php?pg=request.check&id=40293jwx
udv>

Hello, Steve.

We investigated this problem.

The StrsTrim2Len property determines the way FireDAC acts on assigning a
longer value that the field can accept. When this property is on, FireDac
trims the assigned value and doesn't generate any errors, otherwise it
generates the error. But FireDac raises this error anyway on trying to open
inconsistent table, regardless of the StrsTrim2Len property value.

The only way that we've found to open such table is to make mapping of
string type to memo. This way the table opens fine, but the software can't
control maximum length for string fields. so you should use it at your own
risk. Would you like to have such an option?

Sincerely
Sergey Smagin
Product Manager
Active Database Software

mailto: support@activedbsoft.com <mailto:support@activedbsoft.com>
web-site: http://www.activedbsoft.com/

Replies 5

Newest first
Newest first Oldest first

Anonymous

9 years ago

Please try the new version 3.2.5.15. The 'StrsTrim2Len' option is set by default.

Reply Link

thanks for your excellent support and a fantastic program ..

Steve

Sent from my Mobile Device

> On 9 Dec 2015, at 05:03, ActiveDBSoft Support Center <customer-service@activedbsoft.com> wrote:
>
>

Thank you for the sample DB. We successfully reproduced this problem and will turn off this property in the next minor version.

Hi,

Casting them to Memos would work, however the representation of the data would be incorrect.

If I take the same SQLLite database and use FireDAC in Delphi to connect to it, and then simply try to see the data within a table then it produces the overflow error, if I turn on the option in the FireDAC connection editor then I can open the table ( obviously the field is truncated but this is not a problem) and I can create and test the SQL Statements I am looking for.

I understand that the field should not accept data longer and therefore the could be a problem within FireDAC interpreting the data incorrectly, however I was purely looking for a simple workaround to be able to work with the tables.

I have attached the database I am setting up queries for, if you open in ( SQLLITE , no password ) .. and then try and browse data in the configuration table ( and others ) then you will see the notification, if within FireDAC you turn on the truncation then you can access and browse the data.

Hope this helps :)

Steve

From: ActiveDBSoft Support Center [mailto:customer-service@activedbsoft.com]
Sent: 08 December 2015 09:34
To: steve.farmer@elginhill.com
Subject: [ActiveDBSoft / Active Query Builder Support Center] RE: Update on Your Request {40293}
Attachments:
spiceworks_prod.zip

The 'StrsTrim2Len' option determines whether to raise an error or to truncate a value if a value is assigned programmatically to a string field (dataset.FieldByName('stringfield').AsString := 'very long string';). But for the end-user it is impossible to assign a longer value then the field accepts, because data controls (the data grid or an edit box in the form view) don't allow to type more characters than accepted.

As far as I understand, you aren't getting this error on trying to post data to a table, but on opening it. This property will not prevent raising of such error in case of opening an inconsistent table, so it will be completely useless.

What we can do is to make an option to ignore inconsistent data by casting all string fields to memos. So, the question is: do you need such an option?