Re: BI/Report Writer

["Mike Eovino" <meovino@xxxxxxxxx>]

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.