Hey Mike, > I would like to know who is reading the 800 MB report. Regardless...
No one will read them directly. These are generated export files sent to governing authorities who then import for their various reports. I believe various ISO departments for claim management statistics. > I went the route of creating an array of text entries, then for loop the > array to blob, then blob to document. I have been thinking along similar lines today. Just wondering if keeping 2.4 million rows in a text array in memory will be an issue. The text file is 831mb so if 4D can mange it that’s worth a try. Likely faster as one of the reports is taking 3-4 hours. And there are dozens of reports they need to run at the end of the month. That’s why it’s an overnight affair. (Although we could distribute the effort over several computers if we need to.) Thanks for the code snippets!!! John… > On Apr 15, 2020, at 12:21 PM, Mike Beatty <mikebea...@objectivesystems.com > <mailto:mikebea...@objectivesystems.com>> wrote: > > John- > > Re: > >> Hi All, >> >> Sorry for the resend … >> >> 4D v17.2 64bit Windows >> Windows 10 Pro >> >> We have some reports that are run in a batch overnight. Have to because they >> take that long to run all of them. Anyway, since we’ve upgraded from Windows >> 7 to Windows 10 there have been I’m guessing timeouts on some of these >> larger reports. >> >> The report is running along and then we get the error: "executing the method >> “EXP_CumulativeClaims” at the lilne number 63. The .txt document cannot be >> written. File not found.” >> >> This is line #63: >> SEND PACKET($fileRef;$packet) >> >> It varies when it quits. It’s usually saved to a network drive and IT says >> nothing is happening to disrupt the connection. And there are other reports >> where this happens as well. >> >> The text file report size - when it works - is large: >> >> Reserve file: 831,801kb >> Claims file: 26,959kb >> >> So these reports were created way back in 2004. The number of records has >> grown dramatically over the years. Reserves is up beyond 2.3 million records. >> >> Is it possible that this is a client-server timeout issue? If so, how to fix? >> >> Clients IT claims the network drive is always available. Is there a way to >> “know” for sure and test each time? >> >> Is there a way to capture debug info which might reveal the cause? Would >> logging using 4D’s component help? >> >> Would it be helpful and speedier to redesign the reports so they are not >> sending out each row but maybe save each row to a text variable, say 100 or >> 1000 rows and then send packet? >> >> We are open to all ideas. >> >> Appreciate, >> John… > > I would like to know who is reading the 800 MB report. Regardless, I went the > route of creating an array of text entries, then for loop the array to blob, > then blob to document. Looks like this: > > > ARRAY TEXT($atAccountID;0) > ARRAY TEXT($atAccountRef;0) > ARRAY DATE($adCloseDate;0) > ARRAY REAL($arAccountBalance;0) > > SELECTION TO > ARRAY([Account]AccountID;$atAccountID;[Account]AccountRef;$atAccountRef;[Account]StatusDate;$adCloseDate;[Account]OutsBalance;$arAccountBalance) > > ARRAY TEXT($atExportArray;0) > > For ($i;1;Size of array($atAccountID)) > $vtText:=$atAccountID{$i}+<>Pipe+$atAccountRef{$i}+<>Pipe+"WD"+<>Pipe+fDateString > > ($adCloseDate{$i};"YYYYMMDD")+<>Pipe+String($arAccountBalance{$i};"#######.00")+<>EOL > > APPEND TO ARRAY($atExportArray;$vtText) > > End for > > C_BLOB($vbExportBlob) > SET BLOB SIZE($vbExportBlob;0) > > For ($i;1;Size of array($atExportArray)) > > TEXT TO BLOB($atExportArray{$i};$vbExportBlob;UTF8 text without length;*) > > End for > > $vtFile:="myfilename.txt" //standrad file format for client > $vtFile:=fReturnPath ($vtFile) > > > BLOB TO DOCUMENT($vtFile;$vbExportBlob) > > HTH. > > Mike B ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
