7 Replies Latest reply on Apr 12, 2013 5:32 PM by DrewTenenholz

    FM script *steps* fail when triggered from PHP

    rhythmos

      Greetings,

       

      Running into a problem I've never seen before: I'm using FX (not the FM API) to call a script from an FMNew() action. The script triggers, but does not succeed at setting field values with data from an external FM database *file* on the same server. The script works perfectly when executed from the desktop, using the same login as PHP uses.

       

      The data is gotten through a simple relationship (a unique ID string). When executed via PHP, I can update local fields with static data (i.e., a test string), so I know the script is running. But the other Set Field steps simple don't accomplish anything. I tried surrounding the failing steps (there are 4, and I'll need more) with Error Capture on/off, and captured the Get(LastError) value into a local field -- and the error is "0" (zero), both from the desktop (which I'd expect) and from PHP (where it's clearly failing).

       

      I tried setting up a second, separate test file/table, with an analogous 1-field relationship to the local file/table (again, on the same server), and I can update a local field with data using that relationship just fine, via PHP. I've tried turning off the login script on the referenced file, and tried running PHP under a [Full Access] account, all to no avail. The reference file is a pretty complex installation (not of my design, so I'm not yet completely familiar with it). It does use SuperContainer and DataGuard, though neither are invoked in the fields or layouts I'm referencing.

       

      Perhaps interestingly, when I place a copy of the related field I'm trying to extract data from on the layout referenced by PHP, the resulting data array shows the field as completely unidentified (even though the contents are actually visible from the desktop perspective, again, under the same login):

       

      [] => Array

      (

      )

       

      vs. a local field

       

      [Department] => Array

      (

      [0] => QA

      )

       

      or my test related field

       

      [test::Name_First] => Array

      (

      [0] => amy

      )

       

       

      Any ideas as for what to check? I'm stumped -- not a feeling I'm used to and it's really irritating. :<)

       

      In the end, I'll do everything via PHP if I have to, but that'll be considerably more work and harder for the in-house staff to maintain.

       

      Thanks!

       

      PS: The environement is FMSA 11 on Win Server 2008 (i.e., IIS)

        • 1. Re: FM script *steps* fail when triggered from PHP
          LyndsayHowarth

          Do you have the fields on a portal or is the whole table as the basis of the layout?

           

          Lyndsay

          • 2. Re: FM script *steps* fail when triggered from PHP
            rhythmos

            Thank you for responding. The whole table is the basis. I've put a related field on the layout (w/o a portal) from the external table I'm trying to get values from, and that field corresponds to the object that PHP (or the WPE anyway) sees as not even having a name. The test related field I place next to it shows up fine, in terms of both name and value.

             

            I tried a further test today by copying the base table into the external file, reestablishing the relationships within that file, and pointing PHP to *that* table, so that all relevant tables were withing the same file. I *think* it worked -- but it was the very end of the day and I didn't have a chance to convince myself I was correct. I'll get another chance tomorrow, and I'll report back here....Even if it does work, though, it's still not really what I'm after -- but I may have to live with it, if I decide not to go the full PHP route.

            • 3. Re: FM script *steps* fail when triggered from PHP
              LyndsayHowarth

              It has been a few years since I touched FX.PHP... but I certainly do this just fine in FMI's own PHP API. I have several data-separation solutions which are talking to external tables.

              As you point out it is the WPE which is communicating with FM so there should be no difference in the availability of the field to either API.

               

              I will check in tomorrow after you have had your snooze and how to see you've been successful

               

              - Lyndsay

              • 4. Re: FM script *steps* fail when triggered from PHP
                rhythmos

                Thanks again for your interest in this. I've done this kind of thing in FX any number of times before, too (and I would expect it to work in FM's API -- would be awfully limiting if it didn't!).

                 

                I was able to complete the test I mentioned previously, and sure enough, it works fine when the base table (the parent table) is in the same file as the child table. So, something's going on with WPE when communicating when to this child from my external parent -- even though that same task works fine from the FM app/desktop perspective. It perhaps doesn't help that from that external parent table, WPE can see data from a *different* external child table (i.e, I have a good child and a bad child...).

                 

                fmDataGuard is in use in the problem child file, but not all tables invoke DataGuard, so I'm going to try another test against a known non-Guarded table. We'll see.

                • 5. Re: FM script *steps* fail when triggered from PHP
                  rhythmos

                  OK, found the issue, in about the last place I expected (by definition, isn't it always that way?). The answer, as it turns out, is in how the External Data Source is set up. I'd set up the child table as:

                   

                  fmnet:/172.16.0.127/child

                   

                  which worked fine on the desktop (the file is on a remote server). However, I started from scratch, and when I left in the default entry

                   

                  file:child

                   

                  it worked!

                   

                  I would *never* have guessed using an IP address, which strikes me as more specific and more exact, would fail with WPE. Perhaps interestingly, the entry

                   

                  fmnet://127.0.0.1/child

                   

                  works for WPE also -- but not at the desktop, for perhaps obvious reasons.

                   

                  ps. Thanks also to Steve Allen of RC Consulting for providing a fresh set of eyes, which turned out to be crucial.

                  1 of 1 people found this helpful
                  • 6. Re: FM script *steps* fail when triggered from PHP
                    rhythmos

                    Well -- I was slightly too enthusiastic. While the details I mentioned above are true, the problem still remains when trying to access related data in separate file *one a separate server*. This would be a natural consequence of having to rely on the "file:child" style of reference in External Data Sources. So once again, I'm stuck! The limitation crops up in FX & in FM API (version 11).

                     

                    Ideas, anyone?