Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 09 APR 2002 03:16:40PM Michael Slack wrote:

I'm working with an AREV 3.12 application. I have a request from a user for a report that will them be imported into something like Excel so they can sort the data on the fly as they need. They are asking for the report to be similar to one that we already have. That report is a program that formats the output. In looking at the report to mimic, I should be able to do just about everything thru a SELECT/LIST statement except for seperating the column with a comma.

My question is, is there any way to define the column seporator on a LIST statement? I haven't found anything yet that suggests that I can do that.

I may just end up sticking with the normal columnar report and letting them import it into Excel that way.

Thank you for your time.

Michael Slack


At 09 APR 2002 04:58PM Chris Snell wrote:

You could define a symbolic column in the table's dictionary that returns the delimiter you need, and put that column between every "actual" column in the report.


At 09 APR 2002 07:10PM Richard Guise wrote:

We've met this one!

Presume you are looking to preserve Arev records as "rows" in the spreadsheet but to replace the @VMs in multivalues with commas (wot about commas in the data??).

The answer to everything seems to be to write a symbolic! However, the possibilities for symbolics in most apps are pretty well limitless and therefore can result in somewhat cluttered dictionaries!

There's therefore lots one would like to do in reports, exports, etc. "on the fly" (see current discussion on "joins"!). The more so in OI as end user runtimes cannot create/edit dict items.

I'm afraid that our answer has been to identify (largely progressively) these generic requirements (otherwise met by a forest of symbolics). Then write our own T-List report writer, T-Export ASCII exporter and T-Label label printer. Lots of common code between them and between Arev & OI versions.

Benefits :-

1) We don't have to pester RTI or anyone else to get what we and our users need. We just have to devise it ourselves as and when we want!

2) We can do what we want and not what the rest of the world wants.

Having said this, we bought and used Sprezz's S/List briefly. It was really great at what it did and enabled us to avoid a potentially very deep pit! However, what it did wasn't what our particular users wanted. So we just had to bite the bullet!

sorry, I don't feel this is of great immediate help - but I hope it at least adds perspective


At 09 APR 2002 09:55PM Curt Putnam wrote:

I'd suggest using SELECT to get whatever records you want and then feed that to an dBase export. Excel will directly open Dbeast files. No perversions required.


At 10 APR 2002 03:24PM Richard Hunt wrote:

Michael, you might want to try this…

Add (X) at the end of the list statement. This option will not execute the list statement, and it will produce a source code listing of what the list statement will be like. It will prompt you for the "table name" and "row" where to save the source code.

Then you can edit the source code, compile it, and run it.

Note that the actual "select" and "reduce" (the "by" and "with") parts of the list statement will not be included in the source code.


At 15 APR 2002 01:47PM Michael Slack wrote:

Thanks to everyone for there help on this question. Now that I have something to work with I'll see which one I can make work the best for my situation.

Thanks,

Michael Slack

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/a38ad4301717fcfe88256b960069e5aa.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1