RE: Update on Your Request {40293}
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/
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/
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?