Using Delphi XE, I have a JvCsvDataset component that is loading a CSV file which has 27 fields.
When the component tries to load the file I get the following error :
Too many fields, or too many long string fields in this record. You must increase the internal record size of the CsvDataSet.
When try it with a CSV file that has only 24 fields, it works fine.
How do I increase the internal record size of the CsvDataSet?
I've tried to reach Warren Postma who wrote the component but did not hear back from him.
Either specify the length of your fields to stay under the default limit or set the value of TextBufferSize to a bigger value before setting active to True.
From the last answer on
http://issuetracker.delphi-jedi.org/view.php?id=4768
Related
I have Insufficient memory error with TClientDataset with TStringField fields. I need to use length of strings from 0 to 8000 - but don't know what length will be until I fill the TClientDataset.
So, can TStringField be created with dynamic Size?
P.S. The initial task is to copy TDBGrid to TClientDataset.
What kind of data are you storing in those fields to need up to 8000 characters?
Imagine you do partial search on those fields using wildcards. I bet such search would take ages and could posibly even crash your database server.
Besides not all databases tables support 8192 character sized StringFields.
http://docwiki.embarcadero.com/Libraries/XE6/en/Data.DB.TStringField
TStringField encapsulates the fundamental behavior common to fields
that contain string data. A value of a string field is physically
stored as a sequence of up to 8192 characters. However, some table
types may only support string fields of smaller dimensions.
So why don't you use TMemoFields instead since they alow to have dynamical size of their text?
http://docwiki.embarcadero.com/Libraries/XE6/en/Data.DB.TMemoField
I have used the following solution. First, calculate maximum Sizes based on Length(aDBGrid.Columns[i].Field.DisplayText). Then create TStringFields with the calculated Sizes.
P.S. The initial task is to copy TDBGrid to TClientDataset.
I am using Anydac components to access database. TADOQuery is for selecting of data from SQL database.
One of the fields is text, but I need to display some RTF instead of this text (same text but with highlighted words, etc). I tried to create calculated field of BLOB type and fill it with correct value (original text from DB + some processing) in OnCalcFields event of TADQuery. But it doesn't work. I get AV on start of app:
"Field 'xxx' cannot be a calculated or lookup field.".
If I change FieldKind property to fkInternalCalc (default value is fkCalculated) then app starts, but then I get AV at OnCalcFields when try to set value:
"Dataset not in edit or insert mode."
If I define calculated string field (instead of BLOB field), then everything is ok, but string type has another problem. For string type I have to provide Size property limiting max size of the text. And if I use value above 64k, for example 67000, I get AV when try to assign value (even short value!) at OnCalcFields event handler:
Project xxx.exe raised exception class $C0000005 with message "access violation at 0x004094fc: read of address 0xfffffffc".
So, I can create neither calculated BLOB field nor calculated string field. (It is limited in max size and there is no information what maximum size is really safe. I found problem with size >64k, but not sure it will be stable with smaller blocks.)
Any ideas what I am doing wrong?
Update: At moment I have implemented it in a different way. I replace data on presentation layer, but it is just a workaround and question is still here. Is it possible to use calculated fields of BLOB type in Delphi (preferably with Anydac TADQuery)? Is there any information regarding to limitations on calculated fields of string type (or maybe someone has experience how to avoid them)?
procedure TDBDM.CommentsCalcFields(DataSet: TDataSet);
begin
CommentsHighlighted.AsString := 'test';
end;
So, TADQuery has some SQL query, some fields defined + 1 calculated field of BLOB type + OnCalcFields event handler (code is above). It generates AV when I start app (and try to open query). Other things I tried were described earlier.
I am developing a billing system using PowerBuilder 12.5 Classic and I need to set 0 for a textbox; like in vb.net txtchange.Text = 0
i have two drop down list boxes
ddlb_price (defines the price value of an item)
ddlb_cash (the cash amount given by the customer)
sle_change (the change that the cashier is to give the customer)
the system should set the value for sle_change when the cashier inputs the cash.
1. this gives me syntax error;
if cash=price then
sle_fare.settext=0
end if
2. this gives 'incompatible types in assinment
if cash=price then
sle_fare.text=0
end if
The single line edit (sle) control is designed to hold text. You're trying to assign it a numeric value. You will have to change the number into a string if you want the sle to display it:
sle_fare.text = "0"
or
sle_fare.text = string(variableHere)
Once again, I'm going to step back, ignore the actual questions, and look at how a DataWindow would help as an alternative.
You seem to want a control with a data type behind it. The DataWindow has those types of controls. Don't forget that a DataWindow doesn't have to have a SELECT statement behind it; it can have a stored procedure, web service, or nothing at all (external DataWindow) behind the data set. Once you have a control with a numeric data type behind it, you get (for free) some basic editing controls, such as not allowing alpha characters in the field and making sure the entered value is really a number (e.g. "0-.2.1" would fail).
A step beyond that is looking at one of your coming requirements: calculating change. On a DataWindow, you can create a compute with an expression that will automagically calculate your change for you, once price and cash are entered.
I certainly don't want to say you can't do things the way you're proceeding, but there are many issues that a DataWindow would remove over some other approach. The strength of PowerBuilder is in the DataWindow.
Good luck,
Terry
Using ReportBuilder 7.X
Question
Is it possible to Control Print to File.
I need to change the Length of a field at print time
Example:
label2
In the setup - I set its length to 800 which is the max possible this field should ever be.
However, in many cases the record is less than that and i need to set it to the calculated size before printing to file.
Is this possible?
Is it possible to control any portions of this Print to file...at print time (before Print, after print)?
Are the objects avaiable?
We are registered users of the 10.x and above i believe, but have still not gotten around to recompiling are application in Delphi 2009 and the new ReportBuilder....so, that is not an option at this point.
Thanks
Shane
You can try to use the OnDataChange event of the tDataSource that you are using to link your data to your report. This event fires when the current record in the associated dataset changes. In that event, adjust your label to the size for the current record.
i solved this! Each control has a saveLength property. I can just use a global variable that can change at any time (controlling length of entire record). Then just before i print he label, i can set its saveLength property
thanks to all who responded though
Workbook names in Excel 2007 are supposed to be limited in size only by memory, but this appears not to be the case. Eventually, an array saved to a name will get big enough that when you try to save you get (paraphrased): "one or more of the formulas in this workbook is larger than the 8192 character limit, please save as binary file".
OK, so then save it to a binary file format... but even here, an array can get big enough to make saving the file impossible.
What gives? How are names being stored within Excel that this occurs? Is this something particular to the installation? Is there a way around it?
Try it out yourself with the code below. It will run perfectly and the name will be properly populated, but saving will give you somenasty errors. 3351 elements is too many but 3350 saves just fine:
Public Sub TestNameLimits()
Dim v As Variant
ReDim v(1)
Dim index As Integer
For index = 1 To 3351
ReDim Preserve v(index)
v(index) = "AAAA"
Next
Call Application.Names.Add("NameLimit", v)
End Sub
The Names collection is a feature of Excel that has been around for a very long time. The formula length limitation in Excel 2003 is 1,024 (2^10) but was expanded for Excel 2007 to 8,192 (2^13).
These two articles describe the main size limitations for Excel 2003 and Excel 2007:
Excel 2003 specifications and limits
Excel 2007 specifications and limits
To solve this, I would have a look at the Excel.Worksheet.CustomProperties collection. I believe that the Worksheet.CustomProperties item size is limited only by memory. You will have to test this on your system, and probably in various versions of Excel as well, but I think you should be easily able to save well over a 10,000,000 characters.
However, when using the Worksheet.CustomProperties collection, you will be responsible for converting your array to and from a string yourself, unlike the Names collection, which can convert your array to a string automatically.