number of columns in a table field

[Bill Marriott]

Kay C Lan wrote
> Hmmm.. That's exactly why I left Word and Excel behind in 91, bloatware...
> but that is another issue.

I think you know what I mean. Any spreadsheet with a 2000-row limit would be 
very unpopular. But speaking of Excel, the new Excel 2007 will up the limit 
of columns to 16,000 (from 256) and the number of rows to 1 million (from 
64,000). For an in-depth overview of the limits in the new Excel, see

http://blogs.msdn.com/excel/archive/2005/09/26/474258.aspx

> How many fields are you dealing with when you start to see Rev bogging 
> down?
> How much data is in those fields? With the 'on-screen' only approach, this
> could only ever be a factor if you delete entire rows. For single cell
> edits, I just UPDATE that single cell and just SELECT the data back in the
> same cell.

Ok, look at the instance where you want to add/insert one line. You have to 
push at least one line off-screen and write the new information in. If you 
are "paging" your screens it's not so bad. You can lock screen and it 
happens pretty quick. But what if you want to allow smooth scrolling up and 
down, line-by-line? Then each scroll tick requires you to purge a line, and 
update a line, which gets noticeably laggy even when only showing 25 rows of 
a dozen or so columns. Plus a real headache here is maintaining an 
off-screen image of the data and keeping the on-screen representation of it 
in sync. Not so bad when you are working with a fixed-sized display grid, 
but users really like to maximize their windows, display a lot of data, and 
whip the mouse around to different parts of the table. For all the 
shortcomings of the table object it's at least speedy to navigate. Using the 
on-screen-only approach would not be anywhere close to that.

> Actually that's very good. I can see I could use that approach for certain
> types of data and especially for small datasets, more spreadsheets than 
> dbs.
> I'd have to do some experimenting, because every db is different, but for
> the smallest I imagine I could go with the entire data set and load to 
> allow
> 'normal' scrolling. For bigger dbs, I'd probably still stick with LIMITing
> to 50 rows and going with 'stepped' scrolling. I can't imagine roughly 10
> fields of 50 lines of text would take any more that the blink of the eye 
> to
> update - unless of course each line contains 65K char of text.
>
> Thanks for the 'alternate method', now, do I have enough time to whip up a
> quick test stack:-)

The one-field-per-column approach works okay for fairly large numbers of 
rows. Scrolling up and down is handled by a loop which sets the scroll of 
visible columns and is fairly smooth. Scrolling side-to-side is handled by 
scrolling the group. But the problem with the approach is that the scroll 
gets wonky after a while of use; some users cannot scroll to the bottom when 
a large number of rows are present. And the horizontal scrollbar on the 
group is hard to tame. And of course, I have to loop through each column to 
write data instead of just blasting out a tab-delimited line, which is what 
I'd prefer to do.