Can you have an Edittable contain more than one record?

That is if I set column 1 to be associated with the key field.

Then set Column to be associated with data field 2.

Can I populate Column 1 with keys in the CREATE event of the form and then SEND a read event and have the edittable read and populate column 2?

Or do I have to this manually?

Jim,

If backed by LH, you have to do it manually.

If backed by a DataSet, it is automatic.

Cameron Purdy

Revelation Software

LH, so manual it is.

Cam,

I asked you and Gene this same question in the OI class and the answer given at that time was I needed to create a new record in a temporary "Cross Reference" file with a field containing the keys as a multivalued fields within a new record key of this new temp file. Similarly, field 2 would be a multivalued field of items desired for column 2, etc. In other words build a cross reference just for this EditTable. I do not know what 'LH' means but assume that is what you are saying here.

Tom Savell

Cam,

I asked you and Gene this same question in the OI class and the answer given at that time was I needed to create a new record in a temporary "Cross Reference" file with a field containing the keys as a multivalued fields within a new record key of this new temp file. Similarly, field 2 would be a multivalued field of items desired for column 2, etc. In other words build a cross reference just for this EditTable. I do not know what 'LH' means but assume that is what you are saying here.

Tom Savell

CT,

LH is Linear Hash is the standard and proprietary file system of OpenInsight and Advanced Revelation, allowing multivalued and variable length fields. Your tables are probably LH tables.

- Oystein -

Thanks, I actually guessed that LH meant Linear Hashed, but it didn't seem to fit in Cam's sentenence concerning EditTable: "If LH backed then manually." I guess I would have said "OI tables." Anyway, my real point was to ask for further clarification of the word "manually" in Cam's sentence. How do you do it manually.

Tom

Tom,

I'm not sure what you're trying to do. Are you trying to have several rows from the same table at once in your form?

In OI it's easy to create a form that handles single rows from a table. In such a databound (data aware) form you get much for free. Each field in the form is bound to a field in the table. You automatically get read/write/locking logic and stuff.

But I think once you want to have several rows you must do some things manually.

I think you still can have a databound form. But your databound form fields can only be used for one row. If you want to show other rows as well, you must have separate non-bound controls for those. And you must read and write those other rows with your own programming.

In particular I don't think you can have edit tables where you mix the form's "main" row with the other rows.

Another option is to have a non-bound form, where you do all read/write/locking stuff yourself. Then of course you can have all your rows in one edit table.

It really depends on what you want to do with your rows, and if one row is special.

Btw - with MDI you can have several rows at once - one row per child window. If you design your child window as a horizontal strip and tile your child window instances properly they might even look slightly like an edit table. Well, perhaps not.

- Oystein -

Oystein,

Iam discovering that much of my problem is terminology. Iam an old RevG programmer and just starting into OI, so the jargon is throwing me off a little bit: like LH for "Linear Hashed" so please bear with me. I am assuming in your discription that a Data Table is what was called a data file in Rev G such as "Customers" and a "Row" is what we used to call a record in the file which is defined by a unique key. Iam not sure what the "main row" means, perhaps the key??

What I am trying to do in RevG jargon is to create a data entry screen using the EditTable where each row in EditTable is a separate "record" from the "data file". One of the columns in the EditTable would be the data record "key" for that row. In RevG we simply opened the data file and read all the records into an array and displayed the array to the screen. Any user edits to a field in the entry screen (ie: row-column) were changes to the array. When the user saved the screen the array would be written one to the file with each row being a separate record.

I very much appreciate your comments.

Tom

You could do the same thing though what called a collector window. A collector window is a window where no fields are bound to a data file.

In the create event, which is a program/procedure/event that is run when the window is created, you would simple read in each record/row and load the contents into the edittable.

Essentially, you would do this just like loading @RECORD, except you would load it into a different variable and set_property the control to fill it.

akaplan@sprezzatura.com

Sprezzatura Group

Tom,

Table is file. Column is field. Row is record. But I notice even RevSoft staff and experienced OI developers use them interchangeably. I'm not consistent either, but I try to use "table" at least to distinguish from all other kinds of files (and because an LH table really is two (DOS) files).

And edit tables have rows and columns too, but in a different and more visible sense.

In RevG we simply opened the data file and read all the records into an array and displayed the array to the screen. Any user edits to a field in the entry screen (ie: row-column) were changes to the array. When the user saved the screen the array would be written one to the file with each row being a separate record.

You cannot do that in OI, without some programming. What you describe sounds a little like the Table Browser tool that used to be in OI. Table Browser could show sets of rows (records) from any table (in an edit table), and you could change and write back data. (It was removed because it was buggy and unmaintainable.) Btw - it's not unlikely that somebody made their own replacement for that.

If you make a form bound to a table you get the functionality you need for one record. What I meant with "main row" was just that the built-in functionality is just for that one row (record). If you want to you can put separate non-bound controls in your form, where you, with some extra programming, can read other rows into the form. For an example let's say you have a a genealogy database and a form for data about one person. That form would be bound to a PERSON table, have fields bound to various PERSON fields like FIRST_NAME, LAST_NAME, BIRTH_DATE, etc. In the form you could read/change/write data about one person at a time. But you could also have some extra non-bound form fields where you could display relatives of that "main" person. (The example is not too good perhaps, because the fields for the relatives could normally be realised with calculated columns (symbolic fields), and then everything would be fields in the same row, but I hope you get the idea.)

Aaron suggests using the alternative, where you have an altogether unbound form - a collector window. That is perhaps more familiar. (At least it was a familiar concept in Arev.) If so, you know approximately what is involved - programming for reading in rows, locking, writing rows back and stuff.

- Oystein -

Yes, I understand! A few more wrinkles on the old brain did the trick. I think in about 6 months I will be able to make intelligent helpful suggestions to others as you and Aaron are doing. The experience shows.

What I was looking for was the Table Browser you mentioned. I am converting an existing RevG application using the existing data file definitions. Therefore, I do not want to create a new permenant file for the data bound to the EditTable form but rather use the old file defintions brought over from RevG where the data is stored in multiple records with separate unique keys. I think Aaron's suggestion is the way for me to go so I will learn and try that.

Thanks again for your help.

Collector Window is the concept I was looking for. It is not a nice as having the Browser Window that Oystein referred to but it is the next best thing.

Thanks for your help and great suggestions.

View this thread on the forum...