[FX.php List] Weird session variable issue

[Leo R. Lundgren]

Bob,

19 dec 2013 kl. 18.37 skrev Bob Patin:

> Good point… from the link you sent, it looks like anything over 250 characters might fail… then, in the same thread, someone said that microsoft says the maximum URL length is 2083 characters, which we’re definitely not exceeding.
> 
> Here’s the other thing about this error that is so strange: they’ve had over 700 registrations, about 80% of which are done with Internet Explorer (I have a function that retrieves their browser type and version and writes it into their registration); out of these 700, I would guess that about 20 have had these anomalies.
> 
> To make it even stranger, the anomaly isn’t always the same; sometimes we have partial data missing, sometimes ALL the data is missing yet their record gets created. This means that FileMaker didn’t throw an error in generating the record—it just didn’t have anything to write, which points to the session variables.
> 
> I’m going to have to rewrite the app so that it uses the temp table all the time… exactly what I tried to avoid when I designed it.

Why don't you simply take the advice from this thread and actually figure out the problem instead of creating another unwanted workaround for a problem that clearly has a cause? I agree with you completely; You should really not have to change the entire architecture of your application just because of this problem. There's a reason it happens, you just have to find it.

It seems to me that you're not doing the debugging that is needed. For example, to verify whether the URL length issue is a problem, you'd simply log the data that comes into the application and investigate if it's cut off at that point already, in the case when data isn't saved the way you expect. This is on the same topic that I mentioned initially; Track the data and flow of things through the request cycle, in order to find the place where things go wrong.

Again, it's all about isolating the matter to a smaller part of your application, verifying that the what you think is in front of you is really the case (e.g. variables of any kind having the data you think, business logic taking the path you think, etc), and then you should be able to find that the problem happens in one and the same place, and then you're very much closer to an actual solution instead of a workaround. It's just code. Short of memory corruption and other "off" things, which would probably cause other types of symptoms, it's just code that does what you tell it to.

Just saying. I mean, your problem is that data is "disappearing". It doesn't just magically do that at random places in your code. One of the first things you want to know when having a problem like this is at what point data isn't what you expect it to be. One of the last things you'd want to do is changing the architecture without even knowing why.

Regards, Leo

> 
> Bob Patin
> Longterm Solutions
> bob at longtermsolutions.com
> 615-333-6858
> FileMaker 9, 10, 11 & 12 Certified Developer
> http://www.longtermsolutions.com
> -
> iChat: bobpatin at me.com
> Twitter: bobpatin
> —
> FileMaker Consulting 
> FileMaker Hosting for all versions of FileMaker
> PHP • Full email services • Free DNS hosting • Colocation • Consulting
> 
> 
> On Dec 19, 2013, at 11:31 AM, Andrew Denman <adenman at tmea.org> wrote:
> 
>> You mentioned using a GET request with your jQuery call. Could you be running into URL length restrictions?
>>  
>> http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers
>>  
>>  
>> Andrew Denman
>>  
>> From: fx.php_list-bounces at mail.iviking.org [mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Bob Patin
>> Sent: Thursday, December 19, 2013 10:58 AM
>> To: FX.php Discussion List
>> Subject: Re: [FX.php List] Weird session variable issue
>>  
>> Leo,
>>  
>> Thanks for the reply; 
>>  
>> What you should do is debug the application source code so that you isolate the matter. Log the state of the session and its data at strategic points during the requests, so that you can tell exactly WHEN the data goes missing.
>>  
>> Well, I did that; I added a 2nd function to write to a test database after each step of the process. What is interesting is that when this error occurs, even after just the first form (there are about 4 steps to the application process), we sometimes get blank fields on the test database—which indicates to me that FileMaker is creating the record properly, but there isn’t any data in the session variables.
>>  
>> It’s a fairly simple process: I retrieve the form values, save them all to session variables, and then in my test function I retrieve these and write them to a test record. i do this in 4 spots in the process, to see if the data is being retained, and to see where it breaks down. It’s almost as though the session variables just aren’t being written at all...
>> 
>>  
>> 1. There are practical and resource technical limits to how much data you store, but unless you have a lot of data that's hardly relevant. How much data are you storing?
>>  
>> not really that much, but a lot of values; these are names, address, that sort of thing; none of the session variables contain more than about 30-50 characters, I would guess.
>> 
>> 
>> 2. Again hardly relevant unless you are doing something extreme. How many variables are you storing in your session? Basically this and the former point depends mainly on the amount of memory available to PHP.
>> 3. I'm not aware of anything out of the ordinary that you cannot store. Definately not one of those.
>>  
>> That’s what I thought too, but thought I’d ask… 
>>  
>> The other strange thing is that I’m using JQuery validate() to make sure users can’t leave a form without filling it out completely, which ensures that I’m capturing all the values I need to capture. However, I’m beginning to wonder if the GET that I’m using in JQuery isn’t actually retrieving all the values.
>>  
>> Thanks,
>>  
>> Bob Patin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20131219/999bb5b3/attachment.html