Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

SLOW FM database response w/ PHP API

Featured Replies

  • Newbies

Hey Folks, thanks in advance for your help.

I realize this topic may be vague, and if even if all you can give me is a "best practices" response, that will be incredibly helpful. I'm relatively new to the PHP API, but i'm a PHP expert and have been using Filemaker for 20 years.

That being said, my issue is the following:

I have several large databases with 20,000 plus records. All of them respond through the PHP API in less than five seconds when i do a search, or create a record - except for one. It takes 2 to 3 minutes to do a basic insert through a layout that contains only 3 of the fields in the database. We've been pouring over the permissions, logs, etc.

So my questions are:

1. are there any logs that allow me to see exactly what's going on in filemaker as it's happening?

2. are there any best practices docs you can point me to for the PHP API to Filemaker

3. Any common experiences you've had that would cause ONE of the 20 or so databases to be significantly slower than the rest?

Thanks a ton!

Cheers,

Chris

A quick look at you code would be helpful to see if anything problematic sticks out.

I also have a couple of questions. By 'databases' do you really mean 'tables', or do you see the problem when attempting to access any table in a single file? (in older versions of Filemaker each individual file could hold only one table so some developers still refer to tables as databases).

If one file is giving you problems regardless of which layout or table you use the file may be corrupted and need to be repaired. The layout may also have issues. I've seen Filemaker do some goofy things before where simply rebuilding the layout from scratch fixed everything. It's rare but it does happen.

To answer your questions:

1. not really, there's the access log (not helpful here) and the Event log but it doesn't report every transaction, just errors (which might be worth checking), warnings, and "Information" (mostly whether or not backups and scheduled scripts ran )

2. & 3. I think there's a white paper on Filemaker's site Jonathan Stark has some useful information on his site, and some of the early posts in this Forum have some good data. I keep meaning to write something up, but I have a day job. That being said the thing to keep in mind is that the API does not create a connection to the Filemaker databases. So the returned Filemaker object is not a resource handle. The API is simply a series of objects which interface with Filemaker's XML feed via cURL requests. So the limiting step is generally the amount of time it takes the web server on the Filemaker server to generate the XML page. i.e. Any large data set will slow things down.

HTH

Edited by Guest

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.