On 2011-01-24 14:22:45 -0500, Tony Gravagno
<tony_gravagno (AT) nospam (DOT) invalid> said:

As long as you're not outputting too many rows from D3, right?
NebulaXLite is nice for what it does, but I don't believe the issue of
"larger" exports (+1500 rows) from D3 was ever addressed. Please
correct me if I'm wrong on this.

Just so there is no confusion, perhaps it would clear things up if you
stated what you believe the number of rows x columns that XLite can
comfortably export from D3.

--
Kevin Powick

Kevin Powick wrote:

The problem you're referring to was put to rest some time last year.
I don't think we were able to reproduce it on anything but D3 v7.2. I
don't recall what the largest test was, though I was able to generate
something like a 15MB document in 3 minutes. I can go back to that
sometime soon if you wish.

For now, I'm hoping we can keep this thread on topic. Feel free to
dedicate another one to NebulaXLite if you'd like.

Thanks.
T

Sorry for interrupting your AD.

Thanks for the permission. I'll do that.

--
Kevin Powick

On 2011-01-29 09:01:31 -0500, dawn <dawnwolthuis (AT) gmail (DOT) com> said:

I do not believe this is possible with a straight csv import. You
would have to use a data format that your target spreadsheet program
can import, such as HTML, ODF, OOXML, etc.

A nice summary of various spreadsheets can be found here.

http://en.wikipedia.org/wiki/Compari...sheet_software

--
Kevin Powick

I'll preface this by saying that for now I can only respond with
answers to your questions with regard to NebulaXLite. But perhaps you
can articulate what requirements you have for spreadsheets in general
that seem to be unanswered with other tools. I'd like to understand
the divide between what power spreadsheet users expect and what MV
people think they can provide. I'd like this discussion to be broader
than the limited set of tools we are now using.

dawn wrote:
Kevin is right, there is no formatting when you use CSV. CSV is just
delimited data intended for any consumer. There are no instructions
in there which are specific to any consumer application.

NebulaXLite does allow your BASIC code to define column width, row
height, borders, colors, merged cells, fonts, and a lot of other
details. See the documentation PDF on the download page for a
complete list of options.

The documents that NebulaXLite exports can be opened by Excel,
OpenOffice, and Google Spreadsheets. This is possible because the
output is an XML document which conforms to standards. Your BASIC
code can post-process this if you wish to inject things into your
document that NebulaXLite does not. This is one of the reasons why
I've kept this a "lite" product. If I coded too heavily for one
application or another I'd alienate others.

Note that this is also where we can separate the term "Spreadsheets"
from "Excel". (I could have used "spreadsheets" in the subject for
this thread instead of "Excel" but too many people equate the two
inextricably.) Excel is a program that manages spreadsheets, but not
all spreadsheets are Excel spreadsheets. Some nuances of OpenOffice
and Google preclude exchange of some documents, though to some extent
they can be interchanged. While there is a lowest common denominator
amongst these platforms, that LCD is much higher than CSV. I'm trying
to get MV people to raise that LCD to deliver better solutions to
people who expect more.

Dawn, if you'd like to look at NebulaXLite, for now you'll have to
check it out in QM, D3, U2, or jBase. I didn't finish the Caché port
simply for lack of demand, but that situation can change.

Best,
T

On Jan 29, 8:52*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
Tony,
Does NebulaXLite for with Reality?

Thanks,
-Peter G.

On Jan 29, 7:52*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
I no longer have a functioning UniData, UniVerse, or QM
implementations as I once had, but when I get to that point I will at
least take a look at the marketing info on NebulaXLite again.

I will be evaluating what to do for showing users tables online in a
web page along with options for users to turn the same data into an
html report, a pdf or download to a spreadsheet. We have only one
production implementation of an html report, using Cache' Zen reports.
In theory we can turn this into a pdf as well (just a tad bit of setup
and also some recoding there). We also have one live spreadsheet
download. We are using three different approaches for these and might
need to continue to do that, but we are currently generating the data
for each separately and with separate specifications, which is not
cool for keeping them in synch. At the very least we should use the
same query and at best we would not need to regenerate it.

Oh the details! --dawn

dawn wrote:
General response directed to everyone:

I think we're getting closer to the question I was trying to ask
originally. Can you give an example of the kind of "tables" that you
need to render? What are people asking for where Zen, PDF, HTML, and
spreadsheets seem to be solutions? Is the request simply for pretty
reports? Dynamic reports that can be sorted or grouped? Intelligent
reports that allow drilling into detail? Do they really want
spreadsheets because they're Excel power users, or might they be
asking for "Excel" because that's a familiar word.

I'm trying to work out exactly what reporting needs aren't being
satisfied in this market. In some cases people ask for Excel and they
get CSV, which is just one example of where this market falls short.
The real question is - what do end-users need to do their jobs better,
and how can we provide it?

Excel, static HTML, and PDF might be solutions, but what are the
problems that people are describing? Is "attractive" reporting high
on the list for the people you talk to? Are your users more
interested in different kinds of content? Are they interested in
doing other things with the data that you provide? If so, what
happens to the data that you provide? Maybe we can save people some
time.

T

mdsi2000 wrote:

I have Reality and NebulaXLite runs on it, but I never packaged it for
sale. Your note here is the first indication in over 2 years that
there might be any interest in this port. If a Reality VAR requested
XLite for some number of sites I'd do the final work. Otherwise
there's just no justification for that investment.

Same applies for Caché. It seems like once any site moves to Caché or
Reality, they drop out of the traditional MV market. They don't ask
for tools, and therefore very few tools are ported to those platforms.
But I'd love to do more work with both of these platforms and the
people who use them.

T

On Feb 1, 7:11*am, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid> wrote:
Tony,

FWIW, for "attractive" reporting with Excel we tend to operate with
"templates" which already have all the smarts in place in terms of
producing graphs, cross tabs, vlookups etc. End user develops & tests
these, and we save a "template" of the sheet, sans data .... we then
"simply" populate some "data sheets" and we are done.

We tend to just pump data in via script from the database, though we
can also "drive things backwards", and let people design spreadsheets
with data loaded directly from either raw data reads, or by calling
specific backend routines (just pass a HTTP reference, including
values for named parameters, and Visage middleware will call whatever
subroutine with passed parameters, or null/defaults for any missing
parameters.

As current versions of Excel also allow http references for loading
spreadsheets, it then also becomes straight forward to "publish" these
base templates so they can be accessed anywhere, without having to do
things like mapping shares