Problem reading file after using webutil_file_transfer.as_to_client

Question

Hi all,
The Forms webapplication I'm working on has to talk with a cardreading-application on the client-PC. The communication is carried out by exchanging small files. Reading from the client by Forms on the AS goes well (using client_text_io from webutil). The problem arises when the application has to respond back with a file. The file is made on the AS and then transfered from the AS to the client using webutil_file_transfer.as_to_client. This file can not be read by the cardreading application when the AS is on Linux. Our developement AS server is on a Windows 2000 box and then the communication doesn't show this problem.
If I open the file from the AS on Linux , I can see that there is only 1 long line. The Windows version of the file contains 2 lines (as it should be). It seems that before/during/after the transfer some special characters like carriage return and tab are causing the problem.
Looking in web_file_transfer.as_to_client I see that the procedure reads lines from a temporary file into a buffer. The lines are separated by a CHR(10). Could the transfer from Linux to Windows(DOS) cause a problem with these characters ?
Has anyone experienced this problem ? If someone has a clue this would be very welcome.
We work with :
- Forms and AS 10.1.2.0.2
- Webutil 1.0.6
- Development OS: Windows 2000 (Service Pack 4)
- Production OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
- Client-PC OS: Windows 2000 (Service Pack 4)
Thanx,
Enrico

Answer 1

Without going into a long winded answer, the only thing I can really offer is to say this... If you feel as though your code has been correctly written and you simply cannot identify any other possible solution, add SYNCHRONIZE. In short, its execution acts similar to a reset or refresh button.
Another common place where SYNCHRONIZE has been helpful is when calling RUN_REPORT_OBJECT. For example, if you use the code we offer in the Forms/Reports Integration document you will find that it works very well - most of the time. However, sometimes it fails for what seems to be unexplainable reasons. If you message out the values being assigned you will see that some variable values are not being set even though the code execution has already passed the point where a value should have been assigned. Adding the SYNCHRONIZE just after the point where the value should have been assigned forces the assignment before executing the next line of code. For example,
     v_rep := RUN_REPORT_OBJECT(repid);
     rep_status := report_object_status(v_rep);
In the above code, a request for a report is made followed by a check of its status. At this point you would expect that the status would be something like one of the following:
     'RUNNING', 'OPENING_REPORT', 'ENQUEUED'
However, we have seen instances where the value assigned to the variable would actually be NULL, which of course will make the rest of the code likely fail. By adding SYNCHRONIZE the problem is correctable.
     v_rep := RUN_REPORT_OBJECT(repid);
     rep_status := report_object_status(v_rep);
     SYNCHRONIZE;
It is important to understand, however that using SYNCHRONIZE comes at a price. Each time it is executed a network round-trip occurs which will give the application the appearance of degraded performance. So use this built-in only when you know you must.