Running WF 7.7 on AIX platform and have come across a situation that I am unable to find a way around.

We store 8 generations of batch reports in the event our users loose their email original. This storage takes the form of laaaarge flat files. When the report completes the output is saved as a file, wrapped in a mime and then sent out via sendmail. Since it is a file we then uuencode it to base 64 so it has a flat file structure and append it to the massive flat file with some additional data so that we can locate the report by name/date/time and keep all the rows of data ordered.


Retrieval times from these massive flat files has prompted me to try and get the report into a SQL server for storage instead. I convert the file to base 64 and then replace all the unix new line " \n " bits with " ^ " , turning it into one lovely long string. When I retrieve the file, I simply reverse the process and sendmail away...or so was my plan. Worked great for all test jobs but when going to a production report I was faced with "(FOC1347) COMMAND IS TOO LONG " .

I have perused the forums and found discussions on data coming back being too long for display, but I am running an INSERT INTO command to the SQL server. I can " more " the file to see the entire code and if I paste the code directly into SQL Server Management Studio, it executes fine. If we are not using MFD's and executing directly against the SQL Server, why would I be getting this, aren't I running passthru?

I could post the output (the entire SQL statement) here but am a little hesitant as it is one LOVELY long string. Any ideas on getting the string to the SQL Server as is and not have any " edits " attempted by the foc editor/manager?

This message has been edited. Last edited by: FP Mod Chuck,

Is there any chance you could upgrade to an 8.x release? I believe you're manually coding what the Library feature of Report Caster does much more effectively.

https://webfocusinfocenter.inf...rce/rc_library67.htm

Thanks for your reply.

We do have plans to upgrade to 8.x but do not know if the upgrade will include report caster.

From the link you sent about the report library it does seem exactly as you say - I am trying to manually program what the report caster does. Interestingly enough, since we did not purchase report caster, I wrote some unix programs and WebFOCUS fexes that accomplish our overnight batch submissions.

Still on the hunt to see if this is possible since I do not know if Report Caster is coming our way ... would like to check it out one day.

Update - saw another post about SQL using the SQL editor to include an ".sql" file. Tried this method ... took 20 minutes for the copied SQL statement to post into the text box and when executed, Developer Studio crashed.

Thought then could try using it as an external SQL file as mentioned in the wizard. Made a new application, ftp'd the SQL command to that application and went through the wizard again and chose the newly created SQL file.

Well the good news is that Developer Studio didn't crash, bad news is that the same "(FOC1347) COMMAND IS TOO LONG" error is still there.

Still looking for a way to have the editor disregard parsing and just pass the command to the SQL server since the SQL server will execute the command in under a second.

You've a lot more patience than I do. I'd have opened a case with IB Tech Support by now and have them trace the error.

Well, just about gave up but thought of one last trick I could try. My next step will be to try and have the fex execute a Perl script that can call in an external .sql file.

So the fex will make the sql string, save it to a .sql file and then execute the Perl script to call in said .sql file.

It seems normal production responsibilities have caught up so will have to shelv this wishlist item for a bit but will be checking in to see if any answers/ideas come in.