DanShockley

Rather than having a Count calculation field, I'd definitely recommend having a field named something like zFoundCount (in every table). Define it as an explicitly NON-stored calculation equal to: Get ( FoundCount ) That field, as La Retta mentioned above, will know in what context it is being called. So, if you put it in a portal, filtered or not, it will show the number of records in that portal. It also has the advantage of not requiring the reading of the record content in the same way that a calculation field that Counts a data field in the table does. Read this article (from Digital Fusion in 2010) - this technique can produce drastically faster results: https://www.teamdf.com/blogs/a-lightning-fast-alternative-to-the-count-function/ We use this technique in many places throughout our system, and that zFoundCount field is a standard field we put in every table. It made a huge difference in performance and ease-of-development.

Here is the bug report and discussion on this long-standing FileMaker bug. https://community.filemaker.com/thread/133594 Please don't say "problem solved" when there is a bug that prevents people from doing very typical work behavior. Mac and Windows both allow non-file-extension-preceding periods/dots in file name, and most apps work properly, unless that app has a bug. Users should be able to rename files, unless you are saying FileMaker should only be used in very controlled corporate environments. In that case, FileMaker Inc. will need to adjust their priorities in what features they push, right? ;-)

If you have FileMaker Server Advanced, you could use Custom Web Publishing to create a PHP form that saves submitted data into a FileMaker table.

I agree that inserting one row at a time is a good idea, but you also have a syntax problem. The SQL INSERT syntax is this: INSERT INTO table_name VALUES (value1,value2,value3,...) Or, if also specifying the columns to insert into, as you want: INSERT INTO table_name (column1,column2,column3,...) VALUES (value1,value2,value3,...) Your example had the command "SELECT" instead of the command "VALUES" - that might have been the problem. Of course, as you noted, exporting and importing can be pretty fast. There are downsides to that process (stability, control over specific errors, etc.), but it is one of the fastest methods when you need to create a lot of FileMaker records.

Apart from the conversation about what to do with recovered files, it would be great if Sarah (aka "Kansas") could give us the info LaRetta requested. One possibility might be that the computer from which the record was created has clock issues, as someone mentioned. There are ways to avoid that, if the database is hosted, using an auto-enter calc: GetAsDate ( Get ( CurrentHostTimestamp ) )

I had this problem today. Quitting FileMaker and relaunching it did not solve the problem. Just to address those who think it's a scripting issue, it failed when I had a button directly running a Show Custom Dialog with Get ( ActiveModifierKeys ) displaying in the dialog - it showed 0. Restarting my Mac fixed the problem. Not sure how or why.

If you really want search-and-replace within scripts, you can use code that modifies the XML in the clipboard. I've built a useful (but potentially dangerous!) AppleScript tool for searching and replacing within FileMaker objects (not just script steps) in the clipboard, and have shared it on GitHub. https://github.com/DanShockley/FmClipTools NOTE: This is Mac-only, since it uses AppleScript. Also, you can definitely cause problems for yourself if you aren't careful: the search-and-replace can easily replace something that wouldn't normally be user-facing (it runs on the ENTIRE block of XML in the clipboard, not just variable names, for example) and turn what is in your clipboard into something that isn't a valid FileMaker object. So, for example, don't copy a bunch of script steps, then replace "Step" with "MyStep" and then try to paste back into a FileMaker script. Make sure what you're searching for and replacing is something that is definitely unique (e.g. $MyOldVarName being replaced with $MyNewVarName). Any other AppleScript vets out there, please let me know if you'd to collaborate on improving and extending this. I've got a lot of other AppleScript that uses this technique to speed development, but not all of it is stable release.

I'm almost certain 'comment' is correct. If your system runs a DDR on some kind of schedule, you could set up something to parse the XML generated for "Field" nodes whose "AutoEnter" sub-node has the attribute "overwriteExisting"=True. Are you doing this to be able to automate some kind of backup/export/data-transfer process? If you say more about why are trying to do this, there may be other possibilities.

It sounds like the infamous automatic URL encoding bug in Insert From URL. In your sample URI, you have properly already encoded special characters. Unfortunately, the Insert From URL is then double-encoding certain characters like the percent symbol, so the service is getting mangled values for those parameters. Here's what it is probably sending (notice your % are now %25): https://api-ssl.bitly.com/v3/user/link_save?access_token=my_api_key&format=xml&title=Baillieu%2520 Print%2520Collection%253A%25200000.1067.000.000&longUrl=http%253A%252F%252Fgallery.its.unimelb.edu.au%252Fumbl prints%252Fimu.php%253Frequest%253Dload%2526irn%253D105133%2526ecatalogue%253Don%2526view%253Ddetails In your case, you might be able to work around this (although I see this was from July 2013, so maybe you've already done this or given up) by NOT encoding the URI: https://api-ssl.bitly.com/v3/user/link_save?access_token=my_api_key&format=xml&title=Baillieu Print Collection: 0000.1067.000.000&longUrl=http://gallery.its.unimelb.edu.au/umbl prints/imu.php?request=load&irn=105133&ecatalogue=on&view=details Unfortunately for some of us who have cases where we have a mix of characters that need to be encoded, this work-around doesn't help, but it might for this situation.

Yes. He did. His URL (1) shows a properly-encoded %2B. What happens is that the script step silently UN-encoded that into a + when it is sent to the server.

I would definitely classify automatic encoding with no option to turn it off as a bug. Here's an example of where the automatic encoding behavior makes it impossible to submit a search string to a PHP page that includes a leading equals sign to do a search similar to that done in FileMaker (exact word match): If you are crafting a URL that has key-value pairs and the value for one of them needs to be "=Bob" (without the quotes) for example, you cannot submit that. So, your URL would look like this: http://server.example.com/search.php?FirstName=%3DBob That would result in the PHP doing a search for "=Bob" (without the quotes). However, the Insert From URL script step automatically encodes the % in %3D, which means that THIS is what is sent: http://server.example.com/search.php?FirstName=%253DBob That would result in the PHP doing a search for "%3DBob" (without the quotes) and FAILING to find anything. So, you might instead say to yourself "Oh, maybe I shouldn't encode it myself, since Insert From URL does that for me," and use this URL: http://server.example.com/search.php?FirstName==Bob If you do that, Insert From URL sees nothing to encode. OK. Fine. Then, most reasonable web services that are tokenizing that URL would see the second equals sign as indicating the END of the value, so the PHP would get NULL as the value for FirstName and the "=Bob" part would be discarded as superfluous. The search would thus be empty, either returning an error or every record (not just Bob's), depending on your search PHP code. So, the automatic encoding of Insert From URL is a serious liability in that it makes it impossible to submit certain (not rare!) data using it. I really hope FileMaker decides to fix this. The easiest way to fix it would be to add an option to Insert From URL to turn off automatic encoding so that developers can handle the encoding themselves in these kinds of situations where automatic encoding is guaranteed to cause failure. That would also mean we'd avoid any incompatibility with existing scripts.

There is a very useful option when you run the script step "Insert File" - you can choose the "Compress" checkbox to store the file compressed. Helpfully, FileMaker shows the icon and filename of the file in that container without any indication that it is compressed, but there is a lot less data being stored in the database (or external on the server ) and there is less data to transfer over a WAN or otherwise slow network. If you then choose to "Export Field Contents" of that container field, FileMaker silently decompresses that data to export the original file. Having looked at what is stored, it seems that silent compression is the gzip format. Let's say, however, that you want to Base64 encode that container to transfer it via something other than a direct FileMaker import/export or Set. So, you Base64 Encode that container into another field named "Container_asBase64." Then, you transfer that base64 data via a script or an http transfer (perhaps using RESTfm by Goya, for example). You then run that base64 through FileMaker's Base64Decode and the correct file name. You set a container field named "DestinationContainer" to the result. You see the file icon and file name, and it takes up the same reduced space. Then, you Export Field Contents on "DestinationContainer" and save with the original file name to your Desktop. If you try to open that file, it does not work. If, however, you then edit the file name to add ".gz" (gzipped file extension) and then try to open it, your operating system decompresses it and the resulting file can then be opened. You can skip a step by picking the file name with the ".gz" appended when you Base64Decode, but that still means the OS needs to decompress the exported field contents, instead of FileMaker automatically doing that during the export. The problem is that if your OS has no way to decompress the gzipped file, you are stuck. As an obvious example, iOS using FileMaker Go cannot do this within FileMaker. If the whole point was to have a FileMaker Go solution do an http request that gets base64-encoded data, converts it back into container data, and then exports it in order to transfer another FileMaker database, I don't know how to decompress that gzipped file. Thoughts? Obviously, if this isn't possible, it is possible to do this by transferring via a direct FileMaker connection, but it would really be helpful to be able to flip that bit or whatever FileMaker's "Insert File" script step does to mark the container as "compressed" and have alternate transfer methods take advantage of this.

Nice little example of scripting a folder import. On a side comment: to get the parent folder path of the item, it might be helpful to use a custom function like this: // FileParentFolderPath ( somePath; pathDelim ) // version 1.2, Daniel A. Shockley // Returns the path to the parent folder of the given path, using the specified directory delimiter. /* VERSION HISTORY 1.2 - if no path delimiter is specified, use a normal forward slash. 1.1 - rewrote to take advantage of much simpler method */ Let ( [ pathDelim = If ( IsEmpty ( pathDelim ); "/"; pathDelim ) ]; Left ( somePath; Position ( somePath; pathDelim; Length ( somePath ) - 1; - 1 ) ) ) Note that takes two parameters, the file path and the path delimiter (although if you leave the delimiter empty, it assumes you are using forward slash). You'd still need to add "filewin:" or "filemac:" for your code above, but this is an example of when a CF can make code much easier to read and debug or change.

In your Personnel table, assuming that table already has a Full Name calc field and the Current Employee Value field is a Number field with a 1 for active employees, create a calc field named Full Name Current with the following calc: If ( Current Employee Value ; Full Name ; "" ) Then, have your Current Employee Names value list use that calculated field as the second field (with Employee ID# as the first field for the value list) and sort on that second field, instead of the normal Full Name field that has a value for every record. Use all values - no need to have the value list depend on a relationship. This way that value list is available from anywhere, since it depends only on its own table.

One possibility would be to put FileMaker Go 12 (actually, 13 at this point, since 12 is no longer available either) on your iOS devices while keeping FileMaker 11 on your server and Mac/Windows clients. Then, you could use something like RESTfmSync to transfer data between a local-to-the-device FM 13 database and the server. Since RESTfmSync uses the Custom PHP interface, it doesn't matter that the FileMaker versions are different. So, it's possible, but might be difficult. Remember that the iOS devices would then not be working with live data (that can be good and bad), and you have to set up and maintain syncing software. I don't think the other syncing software out there (GoZync, MirrorSync, SyncDeK Mobile) let you sync between a 12/13 database on the iPhone and a FileMaker 11 Server.

Two things: First, I highly recommend building your AppleScript code into a FileMaker variable named, for example, $asCode. Then, Perform AppleScript by calc on that single variable. That makes it easier to debug. Second, the quoting around the string for the do shell script command needs to be all together, rather than two separate pieces. Here's what your script builds: Set Id to do shell script "cut -d , -f 1 ""/tmp/export.csv" set cell ID of current record to Id See how you have double quotes around the cut part and then new quotes around the file path? They need to be together. BUT, it is a good idea to quote filepaths using an AppleScript command that takes care of escaping anything as needed to run in a shell. You also need a line return before the "set cell" part of the script. Here's a fixed version of your calculation: Simple one (without using "quoted form of" - which really would be good to use, since not all paths are as simple and safe as yours here): "set Id to do shell script " & Quote ( $Cut & $tempFileName) & "¶" & "set cell ID of current record to Id" More carefully built calc that will work for any path: "set Id to do shell script " & Quote ( $Cut ) & " & quoted form of " & Quote ( $tempFileName) & "¶" & "set cell ID of current record to Id"

It's not only possible, but the function listed above by "comment" depends upon a function called "CustomList" that does exactly what you want. http://www.briandunning.com/cf/868 Basically, you give it a start and stop value (in your example those would be 1 and 5, respectively) and a string that should be evaluated as a calculation, with [n] holding the place of the "current count." It results in a return-delimited string with the values calculated. So, for your scenario, you would use: CustomList ( 1 ; 5 ; "[n] * 2" ) That would result in: 2 4 6 8 10

We just had this error on our FileMaker Server. The FM Server is version 11.0v3 (not Server Advanced), running on an XServe (2 x 2.66 GHz Quad-Core Intel Xeon) with Mac OS X Server 10.6.4, with 10 GB of RAM. File Sharing is turned OFF, and so are either services. However, I logged into the server via screen sharing and noticed that there is a dialog saying: ------- Conditioning the Apple RAID Card Battery This process may take up to 12 hours to complete and should not be interrupted. Don't restart or shutdown the system until conditioning is finish. Doing so interrupts the process and can cause unintended battery operation. To check battery status, open RAID Utility. ------- I looked online, but cannot figure out whether this would interfere with FileMaker Server's disk operations during backups, which is when the error occurred. Is anyone familiar with this? FYI: We have about 450 GB of free space on the server.

If the clients are using Macs, you could build a little AppleScript application they each have that registers your own custom protocol (e.g. kfutterlink:// ). Then, the AppleScript checks the incoming link and if it meets certain criteria (begins with kfutterlink://, for example), opens up the correct database by scripting FileMaker Pro, puts the URL into a global field in that database, then tells a script in that database to run (and the script processes the URL to do whatever features you want available). The reason putting it in a global field is necessary is because AppleScript can run FileMaker scripts, but cannot pass parameters to them (probably a side-effect of the AppleScript dictionary not being kept up to date with "newer" FileMaker features). Take a look at the following link to understand the protocol part: http://applescript.tv/linktrigger/ Not everything in that article is needed for what you want to accomplish, but it explains how to make an AppleScript applet that is launched when a custom URL is clicked (from within any other program). I've built something like this for our system, along with it handling a custom file extension so we can double-click attachments that are actually FM database files with a custom file extension, watch as the AppleScript applet opens and processes the database in some fashion (running a script in another database that imports it, and so on). I'm following this topic - let me know if you'd like to know more. I may be putting together a how-to on this in the next month or two, either way. Of course, this technique is Mac-only, although I suspect there may be something like it for Windows, even if it involves requiring to build a more traditionally-developed application than the low-barrier-to-entry AppleScript provides.

You can rename a bunch of fields using some kind of UI Scripting, either with AppleScript or with QuicKeys (or some other interface-scripting macro utility for Mac or Windows). Certainly not the most elegant way to do it, but it works. The typical flow I've used to do this is to open the Manage Database window, go to the field list for the table, then click on the row of the first field. Then, the macro does this: 1. Hit Tab to change interface focus to the field name text box. 2. Keyboard command-C to copy the current name. 3. Perform some operation on that name (modify it according to a formula to prepend/append some text, choose the new name from some pre-defined matching list). 4. Type/paste in the new name. 5. Click the Change button. 6. Hit Shift-Tab to move focus back to the field list. 7. Hit Down-Arrow to go to the next field. Then repeat. A very important note: If you are renaming fields, you want the "View by:" sort order to be "creation order" so that the field doesn't move after the macro hits Change, throwing off where you are in the list. Also note that your macro could skip steps 4 and 5 if the field meets a test in step 3 indicating that it shouldn't be renamed. Like I said, not the most elegant way to do it, but functional. I certainly wouldn't use this in a completely automatic way. In other words, I think I'd stick around and watch the macro do the work, and start the process manually. I've even had the macro just run steps 1-7, with a keyboard combo (usually a function key) that I have to press for each field. Simple way to avoid some issue causing it to do something unexpected. Another UI Scripting caveat: Your computer can throw up other dialogs from outside FileMaker that throw this off. Another reason not to run something like this without watching. But, again, if you have more than 20 or so fields to rename, this can save a LOT of time.