dansmith65

So your FM Dev file is changing the dev SQL data AND the live SQL data? If credentials for the dev and live db's are different, then that shouldn't be possible purely from a security perspective. Is something on the SQL side replicating changes?

Can you confirm that in the External Data Source of your Dev file, it's connecting to the Dev_database in sql? I'm pretty sure that's what you're saying you've done, but I want to confirm. This will likely require an additional System DSN to be created, which connects to the correct db, which is then referenced in the External Data Source. https://support.claris.com/s/answerview?anum=000023499&language=en_US

@LaRetta shared this sample file with me @comment and I really liked the concept so I played around with it a little. I was able to accomplish the same result with a single layout, which means I'd be more likely to use this technique myself. I also added layout objects so I could measure the various part sizes rather than having to keep a layout size and script config in sync; this is optional and only my preference for maintenance reasons, though. @IlliaFM Since you just mentioned a footer, I added that to my sample file as well. If you try to use my alternate implementation of this technique, be aware there are two fields layered on top of each other that probably only look like one field at a glance. This doesn't solve the other issues @comment just mentioned, though. MeasureBeforeDisplayDS.fmp12

Open the new window at a specific location, based the existing window's position. So for example, use these values for top and left in the new window: $top = Get ( WindowTop ) + 48 ; $left = Get ( WindowLeft ) + 48 ;

I'd recommend attempting to learn the terminology first. Some of it would be familiar enough to you (tables, records, layouts, scripts, etc.) others might not be (table occurrences, relationship graph, view modes). You can probably get that from the manual: https://fmhelp.filemaker.com/help/18/fmp/en/#page/FMP_Help%2Fsolutions.html%23 Since you're already a developer, I'd say understanding what's unique about FileMaker would be the next most helpful. Off the top of my head, I'd say some of the big ones are: context: everything in FileMaker is accessed through the relationship graph, where each base table can occur 0 to many times and be related (or not) to other table occurrences. A layout is based on a table occurrence, which provides it's context in which it accesses related data. Scripts run from the context of a layout (but you can change layouts in a script, to get a different context). development and deployment platform: FileMaker is an IDE, client app, server app, web app; it does it all.

Sorry, it's been years since I worked on that code and I forgot that I only optimized the "pull" side of the sync. I believe the same concept could be applied to the code that runs on the server when doing a "push", but I never did that. If you want to see if that would improve image syncing speed, you could watch the server resources (memory/page faults) while doing a push. If memory use maxes out, then page faults skyrocket, then code improvements would improve sync speed. This is assuming the push script waits for the server's response, I can't remember if it does, off-hand.

Yes, I was referring to that file. I said not to use that specific file in production because I was doing lots of testing/hacking on it and I think FM crashed while I was working with it... I didn't care because the code wasn't meant for production, it was just a proof of concept. But... You can look at that file, see what I changed, then replicate those changes in your file. It's not easy, or straight-forward, but that's what's available.

The root of the speed issue you're experiencing is explained here: I never did release a new version of my code with the included improvements, but you can see them in the sample file attached to that post and make the same modifications to your file.

Glad you got it to work. To clarify the issue from your first post today; Desktop isn't available to server-side scripting, as per the link posted earlier in the thread. Also, if you were to use my Path module, your code would automatically work on a Windows server as well. Right now, your code would fail if you did that.

BaseElements does not take FileMaker formatted paths, it takes system paths. If you don't want to deal with path format issues, use my module instead: http://www.modularfilemaker.org/module/path/

I would recommend using external container storage for this field, to separate the container data from your FileMaker file. I can't really comment on an external drive vs an internal one, though, as that's not really the deciding factor. This might not sound helpful, but I'm dead serious... The best backup is one that addresses your companies Disaster Recovery Policy. So, if your company can live with a day's worth of data-loss, then your backup procedure would be very different than if it isn't willing to live with more than 5 minutes of data loss. They would also have to expect to pay exponentially more for a disaster recover plan that can guarantee no more than 5 minutes of data loss. That being said, you'll likely want a mix of short-term/frequent/local backups (progressive backup) and longer-term/less frequent/external backups. I've written scripts to send zipped backups Amazon S3, I've heard others that use Dropbox, then there are services like http://360works.com/filemaker-offsite-backup/.

Previously mentioned bug has been reported to FM: https://community.filemaker.com/message/714857

I don't understand the question. It seems to me like you've already identified what needs to be done. I would recommend breaking it down and getting one portion working at a time, doing whatever research/experimenting you need to figure out each step. If you searched through the help file, I think you'd find you can piece this together. For your first step "Open Find" for example, you might want to read this: https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Ffind-request.html. The reference section of the help is useful for exploring what script steps are available: https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fscript-steps-category.html%23 Here is some more general help on writing a script: https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fscripts.html%23

Save your json to a variable, like $requestData, then add this curl option: --data @$requestData Here is a useful post on the topic: https://community.filemaker.com/docs/DOC-8025

I started a trial account for testing and was able to get it to work. I did end up needing to use the BaseElements plugin, but only in one special circumstance, which I documented in the only script in the file. The issue was that FileMaker's CryptAuthCode function returns an empty value if you send it empty data, but that's not what the Unleashed API expects. Luckly, BaseElement's did return data, even if you send it an empty value, so I used it only when necessary. To use the attached file, open the Call API script and add your $apiId and $apiKey. Then on the Layout, you can use the buttons in the header to send two sample requests. Each time you click one of those buttons it will send the request to the API, and record it in a new record. Unleashed API.fmp12

Nobody would expect you to and I'm glad you didn't. Yes, there are some standards, but the bottom line is you need to follow the rules defined by the API you're trying to access. In this case, the authentication is documented here: https://apidocs.unleashedsoftware.com/AuthenticationHelp which states you need an HMAC-SHA256 signature, which can be created in FM16 via https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fcryptauthcode.html. It also states you'll need to set some HTTP headers, which again can be done in FM16: https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fcurl-options.html. If this type of work isn't something you want to deal with, I could be hired to do it for you. In you're interested in that, please send me a private message.

Does this help?...

I'm not familiar with the getCurl function in php, and a google search didn't seem to show it as a common function. I'm guessing it's an application specific function, which means that without a link to documentation, what you've said so far is not helpful in resolving your issue. Can you provide links to published documentation for the API you're trying to access? If not, can you provide any more details about the API at all? If not, I think you'll find little help here; unless I'm missing something obvious. Without more information from you, the only advice I can offer is to use https://httpbin.org/ and possibly http://oauthbin.com/ to debug your http requests.

Going by memory here, but I thought that was used to tell auto-enter calculations that a sync script was running, so adjust your logic accordingly.

The password I defined in the Web Services Manager.fmp12 file's Operations > Edit Auth Info area contained special characters (like brackets). The FileMaker file worked fine with this password, but the wsdl failed to load in the browser saying it was unauthorized. This is likely because the password needs to be urlencoded in websvcmgr.php line 1217: $userPass .= ':' . $pass . "@";

Sorry, I had it backwards this whole time! Now I get why it seemed so strange; it seems strange to me too now. But then again, if you do a regular old find in that number field with the text ASDF3GHJK4QWERTY5, it will match a record with number 345. If you didn't want the text to cause a match in a regular find, you'd have to surround the value in quotes "ASDF3GHJK4QWERTY5", to make it match a phrase.

I think the reason it seems so strange is because number fields weren't meant to hold text and when you put text in them, they won't work like a text field. If you convert that field into a text field, your searches would work as you would expect them to.

Yes, I believe so. Since that field is defined as a number, it's index will only contain numbers. So the index for that value would contain: 301, which explains the match.

@Lee Smith I'm not sure; I'd like to know if it did, though. For the record, here's what I was referring to with the recovery option...

The advanced recovery options allow you to rebuild all field indexes, which is what you did on one field when you followed Lee's directions. You could test that. If that doesn't work; it's going to be tedious finding out which exact field is causing the problem. There isn't any easy way to resolve it; you'll have to just be methodical and work your way through it. Not sure which field it's matching against? disable quickfind one field at a time until it stops matching.