[FX.php List] Weird session variable issue

[Bob Patin]

> 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.

I agree, but I just can’t find it. I added a 2nd function to write to a test DB after each form (there are essentially 5 stages when data gets pulled in and written); when this problem occurs, *nothing* gets written into the test DB. Here’s my simple process:

FORM gets submitted (using JQuery) and GET;
Values are saved into session variables;
Function is called which writes these session vars to a test DB

This fails when this error occurs.

I’ve tested on my Mac dozens of times, with various browsers; I’ve tested on Windows 7, I’ve had a consultant test on XP, I’ve had the client test on her machine using Windows 8. In *all* of our tests, it works perfectly.
> 
> 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.

But the length of the URL is nowhere near 2000 characters; if I had to guess, I’d say it’s 200-300 characters.
> 
> 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.

I agree with all that, but if I can’t duplicate it, I can’t spot it; I can’t even get back anything amiss when I test, so that’s why I’m totally stumped.

If I could duplicate it I could find and fix it; without its occurring on my machines, I don’t know where to turn next. I went through the whole site to make sure that I didn’t have a session_destroy() command somewhere that it didn’t need to be, and confirmed that I’m not destroying the session anywhere but at the end of the process.

The other thing that I know is that FileMaker isn’t failing to create a record; I have error code in there that would email me if that were to happen, but it does write a record—it just doesn’t have anything in it.

I agree that it would be better to figure out the issue, but when 90% of the registrations succeed, and when I can’t duplicate the issue (nor can other testers), I don’t know what else to do…

Frustrating…

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

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