Hi.

I've done a little searching but I can't seem to find the reference to the maximum number of database-bound columns a single edittable.

I can easily use more than one, but this is for a 'hidden' table to just hold data. Any problems with using, say 250 columns?

[email protected]

[url=http://www.arcscustomsoftware.com]ARCS, Inc.

Not really answering your question, but why?

Having a database bound table of 250 columns seems curious, especially as hidden.

It would seem to me that you could do this with a common variable, populated at CREATE and then process and update or whatever.

Colin

Colin,

Thanks for the reply.

Well, there may be a better way. I'm migrating an old Rev G app for a customer and I would not have designed the orginal this way, but I'm thinking I will be able to use his orginal dictionary design pretty much unchanged. It has about 200 mv fields of financial data, 6 values per, 5 years and an interium. The RevG app uses 6 screens to enter and edit all these data and I think I can use a single form with about 6 tabs to provide entry and edit. Only one year of data is displayed at once, and the users selects which year. I first looked at using 200 edit tables and then displaying only a single line and using TOPPOS display the correct line (based on the user's year selection) in each of the tables. I got that working (as a test with about 8 edittables) but the difficulities of locking the displayed cell so the user could edit the data but not move to a differentcause be to abandon that idea. I am now expirmenting with reading all the data into a hidden edit table and then stuffing 200 Editlines, again based on the user's year selection. This is working well in my prototype and I have a promoted event on the lostfocus to handle updating of the hidden edittable to capture any editing of the editline.

I'll soon find out if the hidden edittable can handle 200 columns!

I did not quite understand how your idea could apply. I'm open to any suggestions. If I were designing this from scratch, I'd have about 4 mv fields with description, amount, year, etc. for all this data. The original design in effect uses a field name instead of a description field which is limiting. But the client has used this for 14 years, and says he needs no enhancements…..

[email protected]

[url=http://www.arcscustomsoftware.com]ARCS, Inc.

Oh dear, you have confused me.

There is obviously a lot of stuff going on in your screens which you know best about, and I would not like to suggest a different method of handling this, but just perhaps let you know some suggestions.

When handling large numbers of columns, I tend to have one table on the left of the screen with no scroll bar, and one on the right with a vertical and horizontal scrollbar, and these are placed right next to each other.

By setting TOPPOS you can keep them scrolling together, and the user can scroll the right table and still see the stuff on the left side, eg your descriptions.

This is similar to Excel and the Split function.

Maybe this helps, maybe not, but worth knowing.

Another possibility is to have several tables in the same position on the form. You can resize them in CREATE to make them the correct size and leave them in design mode as smaller screens for editing.

When displayed, you could have a radio button or dropdown selection to make the relevant table visible and the others invisible.

This saves having multiple tab folders, unless you want to of course.

Maybe this will reduce the need to have so many columns on each table.

Another thing you could do is to set TOPPOS to automatically scroll to the left column to set the column for each year, it to move in blocks of 12 months at a time.

Again, without knowing the intricasies of the application…

I also use COLSTYLE to disable the editing of cells when the user moves to a row which should not be edited, on the POSCHANGED event.

I am not sure this is what you are after or not.

Colin

Colin,

I appreciate all the ideas. I have use colstyle to hide columns sometimes when I hold a hidden key and display a symbolic based on the key and stuff like that. As I said before, I've gone away from using the edittable as a direct display for entry/edit, because although I can display a single cell Ok, I have to turn on editmode on gotfocus and (got that done) then prevent any scrolling of the cell, but allowing editing (make it look and act like an Editbox). I'm sure this is possible, but decided to expirment with the other approch of holding all the record's data in a hidden edittable and selectively manage the data for the user in the editboxes (1 hidden edittable and 200 or so editboxes). I have this working for 8 columns and this seems to work well. I'll put a promoted event on the lost focus of all the editboxes that will update the hidden edittable and scale it up.

So, I'm not stuck (at the moment) and having fun and really appreciate all your ideas. This is kind of a plagerizing business or 'standing on the shoulders of those that went before'.

Have a lot of fun!

[email protected]

[url=http://www.arcscustomsoftware.com]ARCS, Inc.

View this thread on the Works forum...