how can i show the records of a table (T1) in...

[alimrb]

how can i show the records of a table (T1) in a table view (for example with a portal) in a layouts (LT1) that the table (T1) is the source of it's (LT1) records.

[cellmaker]

Hmm. Do you mean, I would like to show all of the records for a certain table within a portal in a layout for that same table?(?).

If so, you need to make a self relationship based on something common to each record. For instance, you can have a calculation that returns a constant (const=1). Now make a relationship based that says T1:const=T1:const and call it something like T1_Self.

Put a portal on your layout and declare it to reflect this relationship and add the fields you want to the portal.

You can jump to the different records by making one or more of the fields a button that "goes to related records based on T1_Self.

If that's not what you meant, let us know.

[-Queue-]

You don't need a constant relationship with version 7. You can link any two fields using the 'X' (Cartesian join) operator in the relationship. This will make all records in the tables relate to each other.

[cellmaker]

Alimrb and Queue-

I gave bad advice on the calculated constant but don't agree with the cartesian join in this instance.

First let me correct my mistake. Don't use a calculated constant to calculated constant, which fails when you're creating new records via a portal. Auto-entering a constant (e.g., data = 1) works, or you can set up a global-to-global (same field), which allows creation so long as the global field is not blank. Maybe there's a better method.

As far as I can tell, using a cartesian join does not allow creation of related records. (Queue, you're a Poo-Bah, and I'm not, so if I'm wrong I'd love to hear your thoughts on this.)

I've attached a file showing four different self-types: static (auto-enter data), global, cartesian, and calc.

Creation via Self.fp7.zip

[-Queue-]

You are correct. However, I would think you'd be creating new related records based only on records that are related to the current record. Showing all records in a secondary file would only be for display purposes. There may be some instances where it would be more efficient, but ordinarily it seems like it could be disastrous to have a related record created from a random record in the parent file.

From the original question, it appears we may be delving much farther into what alimrb wanted, though the question isn't quite clear-cut either.

The global-to-global creation is new to me. I can see the relationship benefits for passing data, but for creating new records, something sounds scary about it.

[cellmaker]

Queue -

I like your style. Combative, and yet collaborative.

Though these techniques can be used between tables, I agree it would be kind of strange to create a new record in Table 2 from Table 1 based on, well, nothing.

Creating new records via a portal in one table, however, can be quite useful from a user-interface standpoint, in some cases, especially if that's the method you use in most or all of the solution.

Cheers.

[-Queue-]

Creating new records via a portal in one table, however, can be quite useful from a user-interface standpoint, in some cases, especially if that's the method you use in most or all of the solution.

I wholeheartedly agree. I wasn't questioning the use of using a portal to create new records. I'm only concerned about the idea of using a non-unique relationship to do it.