Groups | Search | Server Info | Login | Register

Groups > comp.databases.pick > #2247

Re: Time for something new for Excel?

Show all headers | View raw

Ross Ferris wrote:

>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.

Thanks Ross - That's pretty much the approach of NebulaXLite as well,
except that the templates are described in BASIC.  This doesn't
require the developer to have Excel and allows for using the final
documents in other environments.  I believe this allows for more
versatility and dynamic changes at runtime, where for example,
customized styling information (as well as data) is incorporated into
the document from  any MV files.  But both approaches are fine.


>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.

NebulaXLite also includes a utility that parses an existing XLS
document for styles and it then generates the BASIC code mentioned
above.  So you can visually design your worksheets, convert them to
code, then use the style definitions in your app code.  This has saved
me a lot of work compared to manually defining styles with borders,
colors fonts and all of the other details for complex sheets.


Trying to keep this on topic - we see that we have created similar
solutions to achieve a similar result.  Great - that goal has been
achieved.  But what end-user needs have we not yet satisfied?  See
other questions in my prior response.

Here are examples:

One of my clients has hundreds of reports that need to be made more
attractive.  They're code is just like everyone else's: They have some
code to create a header, a loop to do PRINT statements with
formatting, some code to display control breaks and sub-totals.  How
do we quickly get from there to a collection of more attractive
reports without manually re-writing every report?  One answer is that
we can't.  Two versions of the report may be required because the
original program doesn't have styling information.  But can we simply
print to some engine that will magically understand where to insert
styles?  Is that the kind of tool that we need in this market?  I know
utilities like this exist, but they can sell for many thousands of
dollars.

The same client wants to offer their reports as Excel.  Different
output formats require different styling codes around data.  Do we
need a tool that allows us to visually map reports into regions so
that we can then export the regions into various rendering engines,
depending on the desired output medium?

Completely unrelated to that, but on topic, people ask about ad-hoc
reporting a lot.  Do we have adequate solutions for end-users to
generate their own reports, independent of IT/VARs?  Or do we need
something new to give end-users more independence, without exposing
schema (dict items), and while preserving user/role-level security?

Thanks.
T

Back to comp.databases.pick | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Time for something new for Excel? Tony Gravagno <tony_gravagno@nospam.invalid> - 2011-01-31 12:11 -0800
  Re: Time for something new for Excel? Mike Preece <michael@preece.net> - 2011-02-02 02:26 -0800
  Re: Time for something new for Excel? Tony Gravagno <tony_gravagno@nospam.invalid> - 2011-02-01 10:29 -0800
  Re: Time for something new for Excel? Ross Ferris <rossf@stamina.com.au> - 2011-01-31 15:54 -0800

csiph-web