[FX.php List] Web traffic versus native FileMaker use

david weiner 1265 at lucerneblvd.org
Mon May 10 10:35:26 MDT 2010


I am working on a Drupal module that brings Filemaker data into Drupal  
through Views. The data is read only at this point by design but it  
might not be a bad place to start if you want to parse the XML for a  
mysql table and/or use Drupal.

You can read more about it and get
the module from my thread at http://groups.drupal.org/filemaker

- David



On May 10, 2010, at 8:41 AM, Dale Bengston <dbengston at tds.net> wrote:

> I am still in the proposal/research stage on this one. The client is  
> driving this; it's just gotten too slow. One of the mitigating  
> factors is, they're self-hosting the FMP client/server solution and  
> I'm dragging data out of it to the web through their broadband  
> connection. Mirroring the data to MySQL would allow me to deploy it  
> on their hosted web server, which includes MySQL and PHP as part of  
> their hosting deal. My current plan is to push orders through to  
> FileMaker as they are submitted; probably using some of my existing  
> ordering PHP code to do a "canned" flip to FMP on submit. I still  
> have some work to do to figure out the data migration from FMP to  
> MySQL. I don't have my brain wrapped around the business rules for  
> when ordering data becomes permanent sales history to feed reporting.
>
> Still, I think it's absolutely doable, and I'm looking forward to  
> the journey. This particular client is my last FMP/web installation,  
> and I'm extremely happy to be moving one step further away from FMP  
> as a web data source. I know that's heresy on this list - but it's  
> reality here. I am still using FX.php for all my web/php/database  
> work, by the way!
>
> Dale
>
> On May 10, 2010, at 10:06 AM, Jonathan Schwartz wrote:
>
>> Hmmm... MySQL.  That option is on my ToDo list. If this is is semi  
>> static data (updated once per week) then  why drag FileMaker into it?
>>
>> Can you provide some detail of how you migrated? In this case, I am  
>> using the FileMaker API, so there wouldn't be that easy switch-over.
>>
>> Thanks
>>
>> Jonathan
>>
>> At 8:38 AM -0500 5/10/10, Dale Bengston wrote:
>>> Coincidentally, my client with the auto-enter calc fields has  
>>> reached the point where reports and order entry into FMP via the  
>>> web are nearly too slow to be usable any more. My resolution is  
>>> also to split the web from the FMP client-server, but I'm  
>>> following a different path. I'm putting the web records into  
>>> MySQL. We're pushing a million sales history records, and the  
>>> design of the system (lots of portal fields) and the volume of  
>>> data is exposing FMP's weakness as a web data source. Why, oh why  
>>> is the XML data pull from FMP so sloooooow?
>>>
>>> I'll be using FX.php to work with the MySQL mirror, as well as  
>>> sync up orders placed via the web with the client-server FMP  
>>> solution. Wish me luck!
>>>
>>> Dale
>>>
>>> On May 10, 2010, at 1:27 AM, Gjermund Gusland Thorsen wrote:
>>>
>>>> If you make layouts with only the needed fields, you should be  
>>>> able to do at least 200 000 records edited or insterted pr hour.
>>>>
>>>> Scripts and additional fields will add time spent, not number of  
>>>> records pr minute to the execution of solution.
>>>>
>>>> ggt
>>>> 2010/5/10 Jonathan Schwartz <jschwartz at exit445.com>
>>>> Thanks for the great feedback, Bob.
>>>>
>>>> In this case, there are 10 modules in the online system, each  
>>>> offering up a different slice of data for web customers.   
>>>> Fortunately, the data for all but one of the modules can be  
>>>> separated off to a separate DB and needs updating only once per  
>>>> week.  The last module...and the busiest...needs to be live  
>>>> current data.
>>>>
>>>> So for the first step of isolating the web modules away from the  
>>>> native system, 9 out of 10 can be done with no issues.  The last  
>>>> module will still need to talk to the mother ship....a step that  
>>>> I can address if and when it is needed.  I will keep Chris  
>>>> Hansen's number handy. ;-)
>>>>
>>>> My original post was to try and work through issues of native  
>>>> FileMaker interfering with Web FileMaker on the same machine.  I  
>>>> have moved past that to work on HOW to separate the two...not IF.
>>>>
>>>> Thanks again,
>>>>
>>>> Jonathan
>>>>
>>>> At 2:36 PM -0500 5/9/10, Bob Patin wrote:
>>>>> Jonathan,
>>>>>
>>>>> I'm late to the conversation, but have some input to share:
>>>>>
>>>>> On the project I'm involved with now, we moved the database  
>>>>> server into the museum for which it was designed. There's also a  
>>>>> web app to go with it, and their IT guys have never been able to  
>>>>> get the web server to work with the database server (you can  
>>>>> imagine how impressed I am with these idiots).
>>>>>
>>>>> So I finally created a 2nd database with only the tables that I  
>>>>> use to sell tickets on the web, and it works fine. Here's the  
>>>>> rub, and why I mention this here:
>>>>>
>>>>> I couldn't find a way to synchronize these 2 databases; I wrote  
>>>>> a script that would pull new orders into the "parent" db, but  
>>>>> without opening the 2 databases on my machine (one on one FM  
>>>>> server, the 2nd on another 700 miles away), I couldn't get the  
>>>>> script to fire.
>>>>>
>>>>> Finally I hired the good Mr. Chris Hansen to write a method for  
>>>>> pulling the data using XML; as you might imagine, his solution  
>>>>> works great, and it gets triggered everytime a sale occurs in  
>>>>> the parent database, which is constant throughout the day.
>>>>>
>>>>> So if you do go to a 2-database solution, where one is doing  
>>>>> just web work, you may keep this in mind as something that will  
>>>>> need to be done.
>>>>>
>>>>> Of course, if pulling the web records can occur less frequently,  
>>>>> you can either have someone do it as they work in the database,  
>>>>> instead of requiring a solution like I used here...
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> Bob Patin
>>>>>
>>>>
>>>> Longterm Solutions
>>>> bob at longtermsolutions.com
>>>> 615-333-6858
>>>> http://www.longtermsolutions.com
>>>> iChat: bobpatin
>>>> FileMaker 9 & 10 Certified Developer
>>>> Member of FileMaker Business Alliance and FileMaker TechNet
>>>> --
>>>> Expert FileMaker Consulting
>>>> FileMaker Hosting for all versions of FileMaker
>>>> PHP * Full email services * Free DNS hosting * Colocation *  
>>>> Consulting
>>>> On May 6, 2010, at 2:47 PM, Jonathan Schwartz wrote:
>>>>
>>>> > Hey Joel,
>>>> >
>>>> > No PHP scripts calling FileMaker scripts.
>>>> >
>>>> > Since writing the original post...only minutes ago....my  
>>>> thinking has matured.  There is stuff going on in the  native  
>>>> solution (not under my control) that will continue to go on. I  
>>>> have now decided to isolate the web solution from it rather than  
>>>> attempt to fix the other side.
>>>> >
>>>> > So, the question now boils down to practical ways to isolate a  
>>>> web solution from a 2 machine deployment, where:
>>>> >     Machine1 = FMSserver 10 with MainDB and WebDB
>>>> >  Machine2 = FMSserver 10 Web Engine, serving WebDB
>>>> >
>>>> > This one just ocurred to me: Turn Machine 2 into a single  
>>>> machine deployment Web Publishing machine running the WEBDB. This  
>>>> will probably mean purchasing another copy of FMServer.
>>>> >
>>>> > Short of doing this, I was wondering if simply adding a new  
>>>> hard drive for the WebDB into machine 1 would be of any benefit.
>>>> >
>>>> > That's where I am right now.
>>>> >
>>>> > Jonathan
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > At 12:12 PM -0700 5/6/10, Joel Shapiro wrote:
>>>> >> Hey Jonathan
>>>> >>
>>>> >> It seems that if your performance picks back up again in the  
>>>> evening, then it's probably not connected to slow record creation  
>>>> (I also had a recent web slowdown due to their FMP person having  
>>>> added auto-enter calc fields based on a bad relationship).
>>>> >>
>>>> >> Are those FM scripts connected to the PHP calls to the DB, or  
>>>> are they being run by users in FMP?  If they're called by the  
>>>> PHP, can you temporarily disable them to test whether or not  
>>>> they're the cause?
>>>> >>
>>>> >> HTH,
>>>> >> -Joel
>>>> >>
>>>> >> ~~~~~~~~~~~~~~~~~~~~~~~
>>>> >> Joel Shapiro
>>>> >> FileMaker Pro
>>>> >> database & web design
>>>> >> http://www.jsfmp.com
>>>> >> 415-269-5055
>>>> >> ~~~~~~~~~~~~~~~~~~~~~~~
>>>> >
>>>> > --
>>>> > Jonathan Schwartz
>>>> > Exit 445 Group
>>>> > jonathan at exit445.com
>>>> > http://www.exit445.com
>>>> > 415-370-5011
>>>> > _______________________________________________
>>>> > FX.php_List mailing list
>>>> > FX.php_List at mail.iviking.org
>>>> > http://www.iviking.org/mailman/listinfo/fx.php_list
>>>> Jonathan,
>>>>
>>>> I'm late to the conversation, but have some input to share:
>>>>
>>>> On the project I'm involved with now, we moved the database  
>>>> server into the museum for which it was designed. There's also a  
>>>> web app to go with it, and their IT guys have never been able to  
>>>> get the web server to work with the database server (you can  
>>>> imagine how impressed I am with these idiots).
>>>>
>>>> So I finally created a 2nd database with only the tables that I  
>>>> use to sell tickets on the web, and it works fine. Here's the  
>>>> rub, and why I mention this here:
>>>>
>>>> I couldn't find a way to synchronize these 2 databases; I wrote a  
>>>> script that would pull new orders into the "parent" db, but  
>>>> without opening the 2 databases on my machine (one on one FM  
>>>> server, the 2nd on another 700 miles away), I couldn't get the  
>>>> script to fire.
>>>>
>>>> Finally I hired the good Mr. Chris Hansen to write a method for  
>>>> pulling the data using XML; as you might imagine, his solution  
>>>> works great, and it gets triggered everytime a sale occurs in the  
>>>> parent database, which is constant throughout the day.
>>>>
>>>> So if you do go to a 2-database solution, where one is doing just  
>>>> web work, you may keep this in mind as something that will need  
>>>> to be done.
>>>>
>>>> Of course, if pulling the web records can occur less frequently,  
>>>> you can either have someone do it as they work in the database,  
>>>> instead of requiring a solution like I used here...
>>>>
>>>> Hope this helps,
>>>>
>>>> Bob Patin
>>>>
>>>> <new_logo_idea3_120w 32.jpg>
>>>>
>>>> Longterm Solutions
>>>> bob at longtermsolutions.com
>>>> 615-333-6858
>>>> http://www.longtermsolutions.com
>>>> iChat: bobpatin
>>>> FileMaker 9 & 10 Certified Developer
>>>> Member of FileMaker Business Alliance and FileMaker TechNet
>>>>
>>>> --
>>>> Expert FileMaker Consulting
>>>> FileMaker Hosting for all versions of FileMaker
>>>> PHP * Full email services * Free DNS hosting * Colocation *  
>>>> Consulting
>>>> On May 6, 2010, at 2:47 PM, Jonathan Schwartz wrote:
>>>>
>>>>> Hey Joel,
>>>>>
>>>>> No PHP scripts calling FileMaker scripts.
>>>>>
>>>>> Since writing the original post...only minutes ago....my  
>>>>> thinking has matured.  There is stuff going on in the  native  
>>>>> solution (not under my control) that will continue to go on. I  
>>>>> have now decided to isolate the web solution from it rather than  
>>>>> attempt to fix the other side.
>>>>>
>>>>> So, the question now boils down to practical ways to isolate a  
>>>>> web solution from a 2 machine deployment, where:
>>>>>   Machine1 = FMSserver 10 with MainDB and WebDB
>>>>>    Machine2 = FMSserver 10 Web Engine, serving WebDB
>>>>>
>>>>> This one just ocurred to me: Turn Machine 2 into a single  
>>>>> machine deployment Web Publishing machine running the WEBDB.  
>>>>> This will probably mean purchasing another copy of FMServer.
>>>>>
>>>>> Short of doing this, I was wondering if simply adding a new hard  
>>>>> drive for the WebDB into machine 1 would be of any benefit.
>>>>>
>>>>> That's where I am right now.
>>>>>
>>>>> Jonathan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> At 12:12 PM -0700 5/6/10, Joel Shapiro wrote:
>>>>>> Hey Jonathan
>>>>
>>>>
>>>> It seems that if your performance picks back up again in the  
>>>> evening, then it's probably not connected to slow record creation  
>>>> (I also had a recent web slowdown due to their FMP person having  
>>>> added auto-enter calc fields based on a bad relationship).
>>>>
>>>> Are those FM scripts connected to the PHP calls to the DB, or are  
>>>> they being run by users in FMP?  If they're called by the PHP,  
>>>> can you temporarily disable them to test whether or not they're  
>>>> the cause?
>>>>
>>>> HTH,
>>>> -Joel
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~
>>>> Joel Shapiro
>>>> FileMaker Pro
>>>> database & web design
>>>> http://www.jsfmp.com
>>>> 415-269-5055
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> --
>>>> Jonathan Schwartz
>>>> Exit 445 Group
>>>> jonathan at exit445.com
>>>> http://www.exit445.com
>>>> 415-370-5011
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>>
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>>
>>>> --
>>>> Jonathan Schwartz
>>>> Exit 445 Group
>>>> jonathan at exit445.com
>>>> http://www.exit445.com
>>>> 415-370-5011
>>>>
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>>
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>>
>> -- 
>> Jonathan Schwartz
>> Exit 445 Group
>> jonathan at exit445.com
>> http://www.exit445.com
>> 415-370-5011
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20100510/9b95da78/attachment-0001.html


More information about the FX.php_List mailing list