Re: BI/Report Writer

Depends upon your database. We've done that in several cases, but we
have some stuff that's so screwed up that you just can't get to where
you need to go with views. Plus, you really do open yourself up to
performance problems letting people hit your production DB. I'm not
going to lie to you, our database is a mess.

Anyway, be sure to think about these sorts of things BEFORE you turn
end-users loose with a query tool. Otherwise, you wind up paying for
it later.

Mike E.

On Mon, Dec 1, 2008 at 9:09 AM, <rob@xxxxxxxxx> wrote:

I often wonder how many complaints about the database would be resolved
with a few simple good views.

User: Why do I have to join this to that? Why do I have to convert this
stupid number to a date? Why do I have to calculate on hand as opening
balance + receipts + adjustments - issues?
Programmer A: Query tools are evil. Use the existing reports. If you
insist on using your query tool you'll just make bad business decisions
because you're an idiot and sliced and diced the data wrong.
Programmer B: Take this here existing query, copy it and change what you
need.
Programmer C: Let me create a view that joins those files for you,
converts that to a date automatically, and calculates the on hand for you.
As a side benefit I'll even change some of the field names to something
that makes sense.
Programmer A: You can't do that! I remember on the original S/38 that if
I added a view it added 1/2 second processing time to a million record
update! Never mind that we are now running a 570 with an average response
time of well under a second and our month end close runs in 5 minutes.
Programmer B: I agree - you can't do that! What if we upgrade our vendor
software? How will we remember to fix the view? Never mind that we
already have customized half of the vendor supplied programs and will have
to fix those already. Somehow we'll just "know" to fix the programs - but
views also??? And, never mind that the vendor is running 8.3.3 and we're
still running version 2.1 from 1985 (converted over from the S/34) so what
are the odds that we'll ever upgrade.
User: Quit your bellyaching. I'll just replace the system with this neat
PC based system. I'm sick of your (expletive deleted).

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
"Mike Eovino" <meovino@xxxxxxxxx>
To:
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date:
11/29/2008 08:42 PM
Subject:
Re: BI/Report Writer
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



Adam,

We use SEQUEL as well. You can use real SQL in SEQUEL ViewPoint. In
Options, set the database to *LOCAL. Bear in mind when you do this
that you lose access to those handy functions. I'd love to see
Help/Systems implement these as real SQL functions.

We are considering a move away from ViewPoint to another tool, but I
wouldn't be surprised if we don't move. We've done too much with
SEQUEL and we have about 100 end-users trained to use it to write
their own reports. Some of our more skilled end-users don't like it,
but all of their complaints are really with our database and our lack
of documentation. If we can ever get permission to build a data
warehouse with good documentation, I have a feeling they won't be
nearly as critical of the BI tool.

Mike E.



On Fri, Nov 21, 2008 at 9:11 AM, Adam Glauser <adamglauser@xxxxxxxxxxxx>
wrote:

I am a SEQUEL user. I'd say that it is great *up to a point*.

Pros
Makes it really output query results to many formats
Includes a tool called ESEND which is a nice way to send email from i
Documentation is good, and both the green screen interface and the
Windows interface (called Viewpoint) are pretty flexible. New users can
be productive quickly due to the handholding options in the both

interfaces

Has its own special syntax which is mostly the same as SQL, so it can
provide some handy functions that "pure" SQL doesn't (numeric date
handling is one area I can think of)
Great support team

Cons
Can't (as of version 8.7.x) call SQL Stored procedures.
Has its own special syntax which is mostly the same as SQL, but has some
significant differences and seems to lag behind SQL features a bit. Some
examples:
- when joining multiple files, can not use different join types for
each joined pair.
- no CTE support

HTH,
Adam
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.