When a device is of type "Rewrite File" the page length is mandatory. This is causing me some grief because I am using this type of device to output a *.csv file.

There is no correct answer to the page length and even when I set the page length to 9999, the file is sized to 9999 rows with or without data.

Is there some way to control this?

What kind of problem do u face in this setup. If u elaborate , it can help us understand the problem.

We use a page length of one on our device that creates interface files for other systems. Of course we do not use any headers.

Mark

I think the best method would be to put the headings in the before.report layout and then just print the detail lines.

Cheers
Neal

When the print device is a file, the system mandates that a page length be defined.

Initially my page length was set to 55. When I output to to this type of device, the format of my file wrote 55 lines of data. Then it wrote two, sometimes 3 blank lines, then 55 more lines of data etc. For now, I have changed the page length to 9999 to eliminate the blank lines. But if my output exceeded 9999 lines of data, the file would still reflect some blank lines.

Since the output is to a file, why even define a page length. I'm expecting the data to be contigious. I can deal with this if I have to.

I'm just wondering if there is a work around or a more generic solution.

I suppose one option would be to create a seperate text file within your report script using functions such as seq.open() and seq.write()

Cheers
Neal

Without page length how would it know when to print headers and such? You have to remember that this is a report running to a file and device. So I think in all fairness a page length should be defined. As I stated our interface files have page length of one and as long as you do not need headers then it should work. Or if you have to have one row of headers use the method Neal mentioned.

Mark

Hi Mark.

Thank you for reminding me that the output is truly a report. I have been fixating on using this method of outputting a csv file to excel or access data base. No headers or footers. Just raw data.

Guess I need to use the seq.* commands.

Joy

Joy,

Please try page length ofone. See the attached image for a copy of the interface file that we have setup. With no headers or footers I would expect this device to work for you- it does for us.

Mark

This worked. Thank you Mark. - Joy

Did you set all of the report margins (e.g. Top Margin, Bottom Margin, Left Margin, Foot Margin) to zero on your report? I think if you did that you would not get any blank lines between pages of data, regardless of the device page length. Of course, you could still end up with blank lines at the end on the last page of data, but Mark's solution would eliminate those.

Francis

Hello,

but if I define page length as you recommend I will get duplicated lines in the output because there is section before.field section in my report.

The interface device that we discussed is really only for a detail layout - no other layouts and no margins as Francis mentioned. This gives you a flat ascii file you can use in other apps.

Mark

But imagine our situation : we have created new session for exporting data from tdpur045 etc. and the output can be seen on display or exported into notepad using special device in Baan. We dont want to see blank lines at the end of the file. Do we have any other option instead of using seq.open in the script ?

I am sure you can do it with a report, but right off hand I can not think how. Even in my Excel device the user understands they need to sort the record to eliminate blank lines. You might be able to run your report to disk, convert to ASCII and the strip out blank lines using a UNIX command. Seems to me someone posted something like that in this forum or the code and utilities forum - you can search those for Excel.

Mark

Here are some parts of code to write a unix script to strip these blank lines...

http://www.baanboard.com/baanboard/showthread.php?t=6662&highlight=excel+awk

http://www.baanboard.com/baanboard/showthread.php?t=9607&highlight=excel+awk

http://www.baanboard.com/baanboard/showthread.php?t=1546&highlight=excel+awk

Different porting sets in Baan Handle this differently. It would seem that in every other release this feature get's turned on and off at the form level. Try to put a page length of -1. this will print a single header and then data without page breaks for the rest. If the form will not allow you to enter it, do it through General Table Maintenance ttaad4100. The logic has always existed, it is the form that they keep changing.

Place a -1 in the page length for the device. Baan will treat this like most other defaults as a non defined length giveing you 1 single header. If the form does not allow you to enter it, use General Table Maintenance ttaad4100. Depending on the porting set, Baan has used field edits on the form to disallow the -1, but the logic has always remained in the code.

It does not help because the output is the same as the old one when the page lenght was 1 and we could see section before.field duplicated. It does seem that there is no other way than use only detail on layout.