From: MM on
On Sat, 19 Jun 2010 08:38:31 GMT, sfdavidkaye2(a)yahoo.com (David Kaye)
wrote:

>I'm in awe that you and whoever else can't see that populating a grid with
>65000 records is lunacy. Nobody can read all that. With more than a few
>dozen rows people eyes begin to glaze over.

"640K ought to be enough for anybody." - Bill Gates, 1981.

MM
From: MM on
On Mon, 21 Jun 2010 21:36:49 -0500, ralph <nt_consulting64(a)yahoo.net>
wrote:

>The next morning I walked in my office to find three boxes full of
>fan-fold print out. I spent a few days pretending to peruse it in
>detail.

Surely you're not trying to say that a grid with more than 65,535 rows
is comparable to three boxes of actual *paper*?

I really do not see what problem David Kaye and others are seeing
here. I can filter the data presented in umpteen different ways, I can
use MergeCells to reduce the number of rows quite dramatically, I can
indeed build a different SQL query and have only a few rows. The
possibilities are endless! But those possibilities are hamstrung if
the grid in question has a bug or if it is restricted by design to a
pitifully low total number of cells.

MM
From: ralph on
On Tue, 22 Jun 2010 06:56:25 +0100, MM <kylix_is(a)yahoo.co.uk> wrote:

>On Mon, 21 Jun 2010 21:36:49 -0500, ralph <nt_consulting64(a)yahoo.net>
>wrote:
>
>>The next morning I walked in my office to find three boxes full of
>>fan-fold print out. I spent a few days pretending to peruse it in
>>detail.
>
>Surely you're not trying to say that a grid with more than 65,535 rows
>is comparable to three boxes of actual *paper*?
>
>I really do not see what problem David Kaye and others are seeing
>here. I can filter the data presented in umpteen different ways, I can
>use MergeCells to reduce the number of rows quite dramatically, I can
>indeed build a different SQL query and have only a few rows. The
>possibilities are endless! But those possibilities are hamstrung if
>the grid in question has a bug or if it is restricted by design to a
>pitifully low total number of cells.
>

Fundamentally, Yes, I AM suggesting that the two scenarios are
identical. The only difference is that in one scenerio the ability to
present and peruse boxes of data has been dramatically improved.

-ralph
From: MM on
On Tue, 22 Jun 2010 08:20:14 -0500, dpb <none(a)non.net> wrote:

>MM wrote:
>...
>
>> ... But those possibilities are hamstrung if
>> the grid in question has a bug or if it is restricted by design to a
>> pitifully low total number of cells.
>
>Only if you insist that the grid is the container for the entire dataset
>instead of being merely a viewpoint into a (reasonable) subsection...

Are 350,000 cells not a very restricting - and arbitrary - limitation?

In any case, I have repeatedly referred to the use of vsFlexGrid's
properties MergeCells/MergeCol/MergeRow which provide for
significantly condensed views of the data on the fly. I have a
checkbox - chkMerge - and I can check or uncheck it and thus instantly
obtain a condensed overview as I wish. I can also see instantly which
columns/cells don't merge and why, and can then apply suitable
modifications using VsFlexString (Awk lookalike).

>
>None of the selection criterion for subsetting you've mentioned are
>affected in any manner whatsoever by there being far fewer than 65K
>actual data lines presented; _NOBODY_ can keep more than a few dozen
>general patterns in mind at one time and even recognize real pattern
>buried in such large morass of data that they can't see just as well in
>a few screens.

This is nonsense. I can spot patterns in half a million rows
easy-peasy just by scrolling through the grid (ScrollTrack =
True).Then I can choose maybe a subset to requery on, or I can sort
the grid columns in either direction (vsFlexGrid has the ExplorerBar
property to facilitate this). I have also implemented search with
highlight in any column with F3 to repeat. I can build whatever tools
my requirements need. That is the beauty of VB.

>The only exception to this would be, of course, structured data where
>there's some order already present such that scrolling down will bring
>up alternative universes within the overall data set -- but having to do
>that manually by scrolling through the entire database at a go is,
>indeed, the same thing as leafing through the greenbar. (And frankly,
>as I age and the eyesight and patience ebb, I'd prefer the greenbar for
>such exploratory stuff if absolutely had to do it because at least with
>it I can use the highlighter and page tabs and so on to have many
>multiple views directly available that a CRT simply can't do...and
>that's a damhikt... :) )
>
>OTOH, if it's a familiar universe of data, I could indeed build the
>relevant queries and get the desired subsets essentially w/o ever seeing
>the raw data other than perhaps a subscreen that gives the ranges for
>the screening variables that might be in the particular database subject
>matter. That would be things like datestamps,
>subject/product/whatever_id, etc., so that the user knows a priori
>whether there's even any point in looking for certain classes of events.
> But that's best done w/ another summary view, not by expecting the
>user to sort thru and guess based on what he can see and remember out of
>thousands of entries of who knows how many variables/record...
>
>$0.02, etc., etc., etc., ...

There are many ways to address your apparent problems. You could apply
a bookmark to mark certain rows or ranges of rows then do a sort to
bring the marked rows to the top. You could select a bunch of rows and
transfer them to another grid. You could filter out rows based on
certain criteria. Finally, you can of course simply re-run the query
underlying the recordset but with different criteria, having seen the
results you got. But please don't tie me up in dogma so that I cannot
obtain a complete overview of my data simply because this offends your
particular design principles! That way is far too restrictive, as is
your claim that "_NOBODY_" can do certain things. You cannot possibly
know what everyone is capable of.

MM
From: Karl E. Peterson on
ralph submitted this idea :
> On Mon, 21 Jun 2010 15:03:25 -0700, Karl E. Peterson <karl(a)exmvps.org>
> wrote:
>
>>
>> Well, sure, but there's never been a model with enough dataspace, and
>> sometimes you just gotta go looking at the raw stuff. :-)
>
> Ha. And if not we would go looking for some way to do so.
>
> Which reminds me of a particular boring episode in my past - a sure
> sign of old age ...
>
> Way back when, when I was young, a C Unix Systems programmer, and thus
> assured I knew everything,

But of course. <g>

> I was contracted to provide a Venix
> workstation access to a proprietary mainframe database (some kind of
> Craig/204 look-a-like).
>
> I was having trouble with the data so I went to the DBAs and asked to
> see the raw records. Insisting there was no way I could make sense of
> the data without it. They had a pained look, but said they would take
> care of it.
>
> The next morning I walked in my office to find three boxes full of
> fan-fold print out. I spent a few days pretending to peruse it in
> detail.

LOL! Well, I bet you didn't ask them *again* for such a silly need,
hmmm? <bg>

--
..NET: It's About Trust! http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org