Setting a global field using php

[jasonwood]

I'm experiencing some difficulty trying to set a global field from php. not getting any errors but when I check the global field, it's still empty.

$findAny = $fm->newFindAnyCommand("php_Products");

$result = $findAny->execute();

$error = error_check($result);

#now I have a FileMaker record object and no errors so far

$record = $result->getFirstRecord();

$record->setField("globalField", "123");

$result = $record->commit();

now, $result is true, which means the commit is successful, but if I do another findAnyCommand, and echo the contents of globalField, I get nothing.

[Genx]

Right, yeh - not gonna work.

You shouldn't be using globals - their values in a hosted environment only last for the duration of a session. With CWP, no Session is by default created, therefore their values really can't be changed as the change will have not even a semi permanent effect.

... why are you trying to store something in a global?

For more info on how globals work, go to faq.filemakermagazine.com and search global fields

[jasonwood]

I have a global field that stores the client number and that allows line items to get the client's price (depending on whether they are a dealer or consumer) by lookup when the line item is given a part number.

I don't want to send prices in a POST, as that would allow people to change the prices.

I'd rather not set php to run a FileMaker script, as they seem to take a while from php.

I can think of a couple other ways to do it but a global is really the preferred option.

You said no session is by default created. Can you change the default? IWP allows each user to have their own set of globals no? Why should CWP be any different?

[jasonwood]

hmmmm... I just read from the site you recommended:

By default, Sessions do not exist with CWP. A connection is made to make the request, and then immediately a disconnection occurs. While sessions can be enabled for CWP to maintain global fields it eats into the max of 100 concurrent connections and so isn't recommended.

So my next question is, what is a "request". Does that include all transactions made by a particular page? Cause I'd be happy if I could set the global, then immediately create a bunch of line items, then end the session... but I think I've tried that and it didn't seem to work.

On the other hand, if I enable sessions in CWP, is there any way to explicitely start and end a session so I don't hit the 100 limit? I only need the session for a few moments.

[Genx]

So my next question is, what is a "request". Does that include all transactions made by a particular page?

- A request is one single executed command so unfortunately, no.

Use a php session... or store that item in a variable, or just store the customers record in a variable... I really don't see the problem.

[jasonwood]

Use a php session... or store that item in a variable, or just store the customers record in a variable... I really don't see the problem.

Yep I'm doing all of those things actually, for other reasons. I haven't gone into detail about what the global does so it is a bit more complex than that.

Suffice it to say that the solution, now that the option to use a global is just about excluded, is not difficult, but it will result in at least one extra transaction between php and FileMaker, and I was just trying to keep it as simple as possible for performance reasons.

[Genx]

A transaction will not likely take more than 1 second in any case - you have to remember that this is a local connection... but what I don't understand is how a global could possibly be any better than a standard field that did exactly the same thing.

If you're looking up prices for a customer based on whether they are a reseller or a retailer for example, you would have the prices table related directly to that customer's field rather than trying to use a global - which would save you the transaction of setting the global in the first place ...to be honest it sounds like your db could do with a little restructuring... that or you haven't explained your scenario very well.

[jasonwood]

If you're looking up prices for a customer based on whether they are a reseller or a retailer for example, you would have the prices table related directly to that customer's field rather than trying to use a global - which would save you the transaction of setting the global in the first place ...to be honest it sounds like your db could do with a little restructuring... that or you haven't explained your scenario very well.

I believe you are suggesting that... I could have a auto-enter calculation field in line items that says if I am an invoice line item, get client ID from invoices, and if I am a quote line item, get client ID from quote. or, if it's from the web and has no parent (yet), then allow the web server to set a client ID to this field. Then the proper price would be looked up based on that field.

And I think that's exactly what I'm going to doing as a result of the new online component.

The reason it's currently based on a global is for no other reason than the global and corresponding relationship was already setup. Once I or one of my staff start "working" with a client record, the global is set and we only see that clients pricing when we browse the pricing (products) table, until we end the call or start working with another client.

It's structurally sound since I don't let users add line items through a portal - it must be done through a script so there's never a worry about whether the global is set.

But yes, a change to the first described method is probably the best bet to accomodate the online shopping cart.

[Genx]

Anywho, looks like you know what you're doing so I'll be leaving you alone. Good luck!!

Cheers.