Page 1 of 1

Delayed writes Causing problem

Posted: Thu May 12, 2005 11:10 am
by rickmds
Hello__I am a Version 11 Xbase user who has 2 reports in a rrwrunin table used to analyze and generate survey results. The first report generates an SDF text file of survey result which is appended to a previously zapped DBF file. This DBF file is used by the second report to display the survey results in a stanardized report format. __This works well when a user pulls 1 - 2 survey reports at a time and then exits the program. When a user pulls 3 or more reports there appears to be a read/write buffer problem and the syurvey result will become mixed & erronous, i.e., wrong results right client, or right results wrong client.__Have you experience a similar problem? Is there a way to ensure a file write when exporting to a text file from R&R prior to pulling the second report?__Thanks__Rick__

=> RE: Delayed writes Causing problem

Posted: Thu May 12, 2005 12:02 pm
by kfleming
Why not just export the first report to DBF directly? That way the a single R&R runtime event will run each report in turn and you are guaranteed that the DBF is complete before report 2 is executed.____Kathleen__R&R Support

==> RE: Delayed writes Causing problem

Posted: Thu May 12, 2005 1:05 pm
by rickmds
Kathleen__I originally wrote this around R&R version 5 and had to export it to a text file because the 1st file consisted of about 25 summary total rows, hence the need to export to text and then import to a DBF. Is there another way to do this with version 11 to avoid the text export?__Thanks__Rick

===> RE: Delayed writes Causing problem

Posted: Fri May 13, 2005 6:21 am
by rickmds
Kathleen__Any further suggestions?__Rick

====> RE: Delayed writes Causing problem

Posted: Fri May 13, 2005 7:22 am
by kfleming
If the total rows come from the same band line then you could export that band to DBF.____Kathleen__R&R Support

=====> RE: Delayed writes Causing problem

Posted: Fri May 13, 2005 7:41 am
by rickmds
Kathleen__Agreed... but unfortunately they do not.__Thanks__Rick