I have a production system with "i" stages (i is a small number, 5 or 6
tops)

At each moment in time there are N(i) items in progress at stage i.

Lets say I sample the number of items in progress at each stage once
each day; so I have i time series which collectively show the state of
my production system (in terms of number of items in progress at each
stage) over a range of days.

Now I want to create a graph which plots each of the i time series
against a common "x" (time) axis simultaneously.

Well, I _could_ put the data onto an Excel sheet and use Excel's
graphing features to produce the graph. No problem.

BUT

I'ld rather collect the data into a central repository (Oracle database
anyone?) so that its in a known place, accessible from "anywhere", under
control and available in the future for audit and retrospective studies.

I could use APEX to set up the CRUD part for data entry ,maintenance,
and subsequent query; so that part is as easy and cheap (since we've
already got APEX in house) as using Excel.

But how do I get the graph? Export the data as csv and import into an
Excel sheet? OK, that would work, but shouldnt there be a slicker way to
fly?

Can I pick up the data from the schema used by APEX and send it through
something like Oracle report writer? Has Oracle report writer got the
graph building bits? Or is there another Oracle tool which will do the
trick?

In the "bad old days" I might have done something like use Excel with
OraExcel (Now called Sql*XL...GJLinker's third party oracle-to-excel
connector) in effect using Excel as a front end for data entry and display.

I was hoping that APEX (plus something for the graphics?) would beat
that. If not, its back to the future, I guess.

On 25.06.2009 18:34, Lee wrote:

You can query the data directly from Excel via Oracle's ODBC driver.
You can even make Excel update the data whenever the sheet is opened AFAIK.

Other than that there are also plotting packages around which can be
used to generate graphs. For example, you can write a perl / ruby /
phyton / your favorite scripting language with database support which
extracts the data and prepares it for graphing.

You can also write SVG easily as it's XML. Plenty of options...

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Robert Klemme wrote:
days it was a bit cheaper. Now they want about 160 euros for the latest
version (I'd be paying in dollars, ouch!). OraExcel now called SQL*XL is
very slick...it has a very nice user interface and is very easy to use,
but I cant see plonking out all that change when all I need is one
table's worth read into the Excel sheet so as to produce a standard graph.

On the other hand, that sort of expense hardly breaks the corporate
bank. What would they (the corporate sponsors) budget for each day of
developer time?


to be cheaper and easier to use Excel, but I suppose there's something
to be said for delivery over the web. I suppose the client side browser
needs some sort of special plug in to render the SVG?




Thanx.

Lee <Lee (AT) Jamtoday (DOT) com> writes:

While a lot depends on the amount of data, I did something similar to
this using a perl script and the GD library. I've also used rdtool for
this type of work. While SVG i certainly one approach, I'm not sure how
many browsers yet support it natively. The nice thing about GD and
rdtool is that many scripting languages have bindings to the libraries
and you can produce images in various formats, including JPEG, PNG, TIF
etc.

Another approach would be to look at existing monitoring tools, such as
Nagios. Such tools often have all the graphics goodies built in and all
you need to do is pump some data at them. We use Nagios to monitor all
sorts of stuff and you get handy little extras such as email/sms
notification when something you have being monitored triggers an event
or passes over some threshold. Its also nice to have all this reporting
goodness in one tool. So, you could, for example, set things up so that
yu get notified if your systems processing falls below or goes above
some value.

Tim

--
tcross (at) rapttech dot com dot au