User Session table

[LaRetta]

I am considering incorporating a User Sessions table. I have searched for 'User Sessions' but can't find examples of it. I have a Global table which is one record with 45 'search' global fields and several system globals and I have a Preferences table which tracks User movement (again using globals).

I believe I may want a record for each user session (?) but I'm unclear on how it would work. I would appreciate any information or links.

LaRetta

[Ender]

I don't have an example, but I should think this could be done by having the login script add a new record when the user logs in, then have the Record ID for this Session record inserted into globals in the tables where you need to access the Session records. Finally, add the relationships between the globals to the Record ID in the Session table. You can also use this Session record to create a log of when the user logs in and out by adding Date/Time fields.

You might consider using a User table instead of (or in addition to) a Session table, where each record is about one User. This might be simpler than a Session table, especially if you already have an Employee table which could be used. In this case, you wouldn't need to add records to a Session table, but simply use the fields in the User table. The relationship could then be between the current account name (an unstored calc or a global) and a stored account name in the User record. One advantage of this is allowing the User's preferences to be remembered across sessions.

[LaRetta]

Hi Mike,

Thank you for helping. I haven't answered because I'm thorougly reviewing all of my options here. Sometimes, because FileMaker allows so darned many ways of doing everything, it can be difficult to select the best methods (for each specific solution). My mind shoots out in 25 directions at once (and I can quite confuse myself with possibilities).

What brought up this question? Posts by CobaltSky, Soren (and others) discussing User tables, Sessions table, server chatting, unnecessary calls between Server and globals, use of graphics on Client stations and a multitude of other (communication) issues between Server and Client - a world I'm just entering.

I think I really like globals. I do NOT think I like them for relationships (necessarily) in a served environment. Portal from Contacts::ContactRep field to LineItems is so much quicker than from global ContactRep field. But my tests are still inconclusive, inconsistent and vague - as is my mind most times.

You've added more pieces to this puzzle picture. Thank you!!

LaRetta

[Søren Dyhr]

Sometimes, because FileMaker allows so darned many ways of doing everything, it can be difficult to select the best methods (for each specific solution)

Indeed, thats why I posted this:

http://www.fmforums.com/threads/showflat...true#Post164164

I do NOT think I like them for relationships (necessarily) in a served environment.

I must sadly confuse the matters even more by turning your attention to that it only matters when one of the key fields are globals and the other has an index attached ...if both fields are global is it although it's regarded an illegal relation by the RAD due to the missing index in the child end of the matter. But turning off the indexing this way when transfering values over a relation actually speeds things up.

http://www.kevinfrank.com/download/df_invalid_relationships.zip

Network chatting is always caused by the transfere of large indexes, not by the globals as such, but having them in calculations causes this transfere to happen more often but if the index is short nothing will be noticed. But pushing values to other tables smells a little of denormalized structure ...which can have it's genuine purpose. So reserve this feature to the transfere of recordID's for linking purposes.

But the storage of temporary values in globals isn't my style, do I usually prevent myself from by turning my scripts recursive, if a metaphoric objects calling of the script isn't that obvious in the context - so I can exploit scriptparameters to their full extend.

http://www.coresolutions.ca/filemaker/issue/28/default.php

...one thing the .pdf didn't mention is somthing you discover when making recursive script and run them thru the debugger is the stacking of parameters, that I still have to think up ways exploit, the outer calls keep their value until their cycle is finished - but this means that you need to get the previous parameter into the call of the new one if you would need it there.

But the storage of user specific default values in a set of records can be accomplished by having Get(UserName) as linkfield for the relation, allthough linking with real values is questionable ...but as long as it's kept out of reach from the user interface can't much harm be done. As an extra bonus will the related records last after the session, which is more iffy with globals as such.

--sd

[mcbrady]

I use a "UserProfile" table with a one-to-many relationship to a "SessionsLog" table.

As part of the open script, each user creates a new record in the Session Log via this relationship. During the close script, this same record is found, and a log out timestamp is stamped on it.

It works great to track all the coming and going of users, both on a platform version, and the web-published version. The worst that happens occastionally, is that they are improperly logged out/disconnected, and the server completes the session 15 minutes later. The script also makes note that they were bumped.

I also use a tag on the UserProfiles for my quick look at "Who's Online" script.

Has come in handy during many a "labor dispute"