Session tracking

[DonH]

How does FM 3.0 keep track of the different sessions and users? Cookies?

[Anatoli]

Could you rephrase that question? Cookies = web.

FM3 doesn't work on web.

[DonH]

I have 200 people connecting to the FM application at one time, how does FM keep track of who is doing what?

And cookies just generically refers to putting something on the client to keep track of the session. So doesn't necessarily mean the web tho that is what most people associate it with.

But there has to be a marker stored somewhere seperating the sessions.

[Fitch]

FileMaker 3 has Status(CurrentUserName), here's an article about how to use it:

http://www.filemaker.com/ti/103729.html

Can't remember if that was also an auto-enter option back in that version. Is that what you're looking for?

PS: Seems to me cookies and sessions are both browser-related, developed to compensate for the "stateless" nature of the browser. If you have a reference for other usage, I'd be interested to see it.

[Anatoli]

RE: But there has to be a marker stored somewhere seperating the sessions.

What do you need? I am working 11 years with FM and I never hear about sessions.

What is session to you? How does it relate to FileMaker?

[Vaughan]

FMP handles all that stuff internally and invisibly, so we don't need to bother.

Part of its technique is to use record locking (so only one user can work on a record at a time) and automatic saving of data (the moment a client exits a record the database is updated).

Think about it: if the database is always kept up to date, and users cannot simutaneously work on the same record thereby avoiding concurrency issues, then there sin't much else that needs to be done.

[DonH]

A session is anytime a person enters your application for any reason. So if I have a doctor wanting to enter notes on a patient, he has a session. When he logs out, his session ends. This is true of ALL applications that allow multi-user connections. Not just web based.

With the db you have to have transactions and locking to keep from having conflicts and possible data corruption.

To keep track of who is doing what, sessions are marked in some way. It wouldn't be very good if Customer X wants to see info on product Y and Customer Z is buying product P and Customer X ends up buying it. Thus some method of seperating them is needed.

Down thru time we have called these different things. Markers, tokens, tags, cookies, and a few others. These are implemented in different ways. For the browser cookies they are stored on the client. But you can also have session labels that go with the URL or are even stored on the host.

Languages such as Cold Fusion allow you to utilize variables that pertain just to sessions or clients. So if a person logs on and I want to keep track of their first name to customize pages, I can do something like client.firstname=(name retrieved from database). Then anytime I want their name I just put in the variable client.firstname and there it is.

Using sessions there is also usually a way to time out a session forcing the client to log back in.

The reason I am asking is that there appears to be data corruption based on crossed sessions. The above example is a good one but more to the point, Doctor A does an exam on Patient B. He has a number of patients to see so he doesn't enter Patient B's notes right away but leaves the layout with that patient's info open. Meanwhile Patient B goes into labor and is admitted into the L&D ward. They enter the data regarding the admittance and observations. Now Doc A goes in and enters his info and it wipes out the L&D info because his data was not up to date. This is what APPEARS to be happening in some cases. Of course that exact set of circumstances is rare.

So I was looking at how FM tracks the clients/sessions to see about timing out or auto refresh of all clients having a certain record open.

[Anatoli]

RE: Languages such as Cold Fusion

The same is with FileMaker *and* Lasso. It has to exist on web, but as Vaughan pointed out -- doesn't exist in FileMaker "outside". The record locking works just fine.

RE: The above example is a good one but more to the point, Doctor A does an exam on Patient B. He has a number of patients to see so he doesn't enter Patient B's notes right away but leaves the layout with that patient's info open. Meanwhile Patient B goes into labor and is admitted into the L&D ward. They enter the data regarding the admittance and observations. Now Doc A goes in and enters his info and it wipes out the L&D info because his data was not up to date. This is what APPEARS to be happening in some cases. Of course that exact set of circumstances is rare.

Doesn't happened in FileMaker *never*.

As soon as Patient B record is amended somewhere, screen for Doctor A is refreshed in split second after the L&D ward finishes. So no wiping of someone data.

Trust us, hey, do not trust us, get 2 machines and try that.

There are some tasks in which record must be locked programmatically in CF, Lasso or FileMaker. But that is not your case.

[BobWeaver]

First of all, are you referring to Files hosted on FM Server, or files hosted by a regular copy of Filemaker, or possibly files shared by file sharing. If it's the latter, then it is guaranteed that the files will become corrupted. FM files can only be shared by the hosting option on Filemaker, or with FM server. And in that case, Filemaker automatically keeps track of which client is doing what to which record. (The host internally assigns a session number to each client, but the user never sees this.)

When one user clicks into a field in a record, all other users are locked out of that record until the original user exits that record (at which time, the original user's changes are saved). So it is not possible for another user to edit the same record at the same time.

[DonH]

Well, it is hosted on an FM Server and we have had a couple of cases of Doc A opening a file and inputting data. Meanwhile Doc B opens the same patient file and quickly adds info and closes the file. Then Doc A finishes and Doc B's info is gone.

Sounds like the locks aren't that great. Hopefully they made them better in later versions.

But it sounds like everything is done behind the scenes and no checking of the session tracking is possible. That is the basic answer I needed.

Is it possible for Doc B to see that somebody else has the same record open? I think I've seen that at some point. Something comes up saying the record is locked?

Oh well. Back to trying to incorporate everything onto one server. groan

[Vaughan]

"A session is anytime a person enters your application for any reason. So if I have a doctor wanting to enter notes on a patient, he has a session. When he logs out, his session ends. This is true of ALL applications that allow multi-user connections. Not just web based."

Ahhh, these are transactions, not sessions.

Yes you can get FMP to log transcations, but it's a lot of work. Somebody else will know more details I'm sure, there is a demo around the net somewhere.

What you complain about has nothing to do with recod locking since the users are not working on the record at the same time. You have what I call a "political" issue, not a technical one. You need to get the users to check before they edit records.

[Fitch]

Don, it's possible that your db is set up in such a way that it appears that Dr. A and Dr. B are editing the same record at the same time. Maybe you're using global fields for data entry, or some other mechanism. The fact remains, FileMaker does lock records, and 2 users absolutely cannot modify a record at the same time. You WILL get a "record is locked" alert.

[DonH]

"Ahhh, these are transactions, not sessions."

Uhmmmm no. A session is the time a person goes onto an application to the time they leave. They may just browse thru records or they may enter data. A transaction is when there is an exchange of data such as inputting new information. Transactions can be rolled back (not sure about FM probably not tho) like if the person hits "CANCEL" before completing a series of steps.

Maybe an example will help clarify the differences between clients, sessions, and transactions.

Let's say you have a store. I walk in off the street for the first time. I have just started a session. I cruise the store looking around and find nothing of value to me. I walk out. The session is now closed.

Next I walk into your store (opening a session) and find something to buy. I am now a client. (When I give information that will identify me) When I go up to the cash register to pay I am starting a transaction. If at any point my wife walks in and says "PUT THAT BACK!" The transaction is rolled back as if it never happened. IF I hand over the payment and get a receipt, the transaction is completed. When I walk out the door the session is closed. BUT I still remain on the records as a client. Next time I walk in you greet me by name because I am a client.

Fitch --- since I didn't write it, there could be ANYTHING going on. I have such a headache from tracking down sloppy code in this thing. You are probably right about global variables. There are a zillion of them in this application. I think he made EVERYTHING a global field plus a local field.

I'll focus in on that tho and see if the entries are being made on global fields. I bet they are. groan.

[Anatoli]

RE: Well, it is hosted on an FM Server and we have had a couple of cases of Doc A opening a file and inputting data. Meanwhile Doc B opens the same patient file and quickly adds info and closes the file. Then Doc A finishes and Doc B's info is gone.

YOU ARE NOT SERVING THE FILES THROUGH FILEMAKER SERVER!

THIS CANNOT HAPPEN! PERIOD!

Only if someone overwrite knowingly Smith to Knight within the same record.

[Fitch]

"I'll focus in on that tho and see if the entries are being made on global fields. I bet they are. groan."

Groan? Not necessarily. This is actually a common technique that is used for scripting data entry in FileMaker, to give the developer more control over the record creation and verification process. But it also means you have to deal with record "locking" yourself, e.g. by setting a field value and then trapping for that value in your data entry scripts.

[DonH]

"THIS CANNOT HAPPEN! PERIOD!"

FAMOUS LAST WORDS!

I think Custer said something similar about the Indians whupping on him. So far I've had things happen with FM that people have said the same thing about. But they DO! Some of it is bad programming. Some is maybe due to running 3.0 on Win2k, but some of the incidents can only be left to either bugs or bad design on the part of FM.

Fitch - That is why I mean groan. Having to go thru all the code and make sure everything is locked properly. With all the work I will have to do to bring this app up to par on security, data integrity etc etc, I could just start over. And since it will be replaced in the next 6 months, I have to decide whether or not the time is economically justifiable. Since this only has happened a couple of times (and I can not reproduce it) I will probably let it slide and worry about things like why some files are getting "security errors" on them now.

[Fitch]

"Some is maybe due to running 3.0 on Win2k, but some of the incidents can only be left to either bugs or bad design on the part of FM."

Perhaps some of the problems could be due to PEBKAC.

[DonH]

I probably don't want to know but what is PEBKAC?

[-Queue-]

http://pebkac.net/