String Size Exhausted

[stanl]

Not sure about this. I have a request to query SQL Server Data, and export as .csv with Ascii(263) as the field delimiters and LF as the line delimiter - re-package with gpg and upload to a NAS.

I've had no problems with this, using ADO's getstring() and calling a variable-ized batch file for the gpg. However, when extracting historical YTD data after ten months worth I received a "String Size Exhausted" error and the script terminated. I quickly reduced the size of the pull and went on with YTD w/out issue. The .csv size before the gpg compression was still under 65k if that was the issue... So is this a WB limitation of Getstring()...?

[JTaylor]

I am doing the following with 299k of info and it works.

Does your script look similar or do I need to tweak mine to match for testing?

Jim

Code (winbatch) Select Expand


    SQLText = " Select * from resources"
    myRS.Open (SQLText, myConn, adoConst.adOpenStatic, adoConst.adLockReadOnly, adoConst.adCmdText)
    If myRS.EOF == @FALSE Then
      txt = myRS.GetString(adoConst.adClipString,1000000,Num2Char(263),@LF)
    EndIf
    myRS.Close


[stanl]

Jim;

That is pretty much it. First I collect the field names for csv headers, run the getstring(), concatenate with the headers then perform a FileWrite. Like I said, it could be a once-off and I will not have to worry about size in the future.

[td]

There are no special limitations on the size of a string returned by 'GetStrings' in WIL.  The only WIL restrictions are the same ones imposed for any other string, i.e., available string space and available process  memory.  Neither of these limits are fixed but string space starts out at 250MB and process memory starts at something greater than 250MB.

[DAG_P6]

Stan,

Jim;

That is pretty much it. First I collect the field names for csv headers, run the getstring(), concatenate with the headers then perform a FileWrite. Like I said, it could be a once-off and I will not have to worry about size in the future.

Very rarely, I've had such things happen when my code did a lot with strings within the scope of a single routine. Generally, I was able to solve the problem by moving the body of the loop into a UDF, so that the strings acquire function scope, and are destroyed when the function returns.

Following is a pseudocode example.

Code (winbatch) Select Expand

while MoreWorkToDo
    sItem = GetNextItem()
    ProcessOneItem(sItem)
    sItem = ''
endwhile  ' while MoreWorkToDo


Hopefully, the above example makes sense as it stands.