To use your temporary table, you'd need to add a field that records the current account or user name, then filter out all records that don't have the current user's user or account name. If this table is displayed in a portal, that means your portal or the portal's relationship can filter out all records not marked with the correct name. In a list or table view, you'd perform a find for this. (Or you may be able to start with an empty found set and then the script that creates each new record whether by Import Records or in a loop sets up a found set only the newly created records--which will only be visible to the current user...)
A temporary table, however, isn't actually necessary for such a cross tab report. There are ways to use portals in a list view to get your columns of data without physically copying the data into a temporary table.
Thank you for the reply i will try to implement that.
When you said a temporary table is not necessary...
I like to add more info .... it is not just a cross tab report I actually have invisible buttons over every cell of the grid (portal contents) so when the user clicks on it the program knows which teacher and which time is selected for booking ar otherwise. And also I use conditional formatting to color each different type of appointment (I know conditional formatting is slow but I know of no other way).
If you still think I can do that without using a temporray table I would love to hear your ideas.
Thank you again.
As a side note not directly related to the layout your are trying to create
I tend to use tables of global fields with a non global userID field. When entering the layout I find the record that matches the accountname (or add a new one if none are found and populate the account name)
As to Phil's comment I use the temp tables when I want to write out to multiple tables and to control the "save" of information. I can perform complex validations etc. While you may not need to use a temp table it can be useful.
It all sounds possible, but I don't know the structure of your data nor the table you want to produce here. As always, the devil is in the details. Likewise, it's crucial to know whether you are using FileMaker 11 or not as the portal filter feature newly added in FileMaker 11 can be very useful here.
Let me try more on my own and if I do not succeedd I will forward the structure and more info to ask for fufther help if you have the time to spend with me. and yes I am using FM11 advanced.
For now you idea of filtering using acoount name will do, but eventually it would be more efficient not to use temporary tables.
Thank you for your note but in my case using global fields will not help because I generate many records for each case so I need the records to contain different values not to be global. Unless I am missing your point.
nope you are correct. I use globals when I can though as you state in your case you cant. Temp tables, global or otherwise, have their uses. Mostly to control changes in the database though.