Jump to content

Brian C

  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Brian C

  • Rank

Profile Information

  • Gender
  • Location
    Portland, OR
  • Interests
    FIleMaker Cross-platform Development and iOS (iPhone,iPad,iPod)

Contact Methods

  • Website URL
  1. Just got FileMaker 13 Certified!

  2. It has been my experience that filemaker FQL does not like it when you mix aggregate functions with non aggregate functions. If you have Filemaker Advanced you could write a recursive custom function that processes your SQL array result to arrive at the desired result.
  3. I agree with Wim. Never use the existing database files after a crash. Always replace them from your last good backup. This may mean having to recreate data already input following the last good backup but it will save you a lot of trouble compared to what you will have to go through later on if your files become corrupted. You might want to think about adding more backups to insure you don't too loose much data entry. The 'Automatically Start Database Sever' option should never be used. If you are making use of 'Enable Progressive Backups' feature, it becomes even more critical to not use the autostart option. If you do, you risk overwriting your progressive backup with bad/corrupted data thus negating it's entire time saving purpose.
  4. You could also use SQL to accomplish this. Set Variable[$result ; ExecuteSQL(" SELECT Type,count(Type) FROM MyTable GROUP BY Type ";"";"";"") ] This would give you exactly what you are looking for as well, but if you need to do anything specific with the result you will need to parse it. Be careful if you suspect your query will need to process/return record sets > 500. FileMaker will do it, but performance degrades quickly if the resulting data set that has to be processed is too large. Use of the WHERE clause is very important when dealing with SQL in FileMaker to keep your performance up to snuff.
  5. The preferences you are looking at refer to what FileMaker will use as the default font when you CREATE a file. Unfortunately you cannot change the default font of a file after it has been created. You used to be able to change the default font for a layout by changing selecting a font while you do not have any objects selected, but it seems that we no longer have the ability to do this. So it seems that your only solution is to use Themes to control the fonts in v12 and 13. v12 has the Remove All Styles button which exposes the default font. v13 is missing the Remove All Styles button, so I believe you must really completely on Themes.
  6. Another approach is to export the data to a fm formatted file and do your updates to the data and then import the data back in again without using the auto enter option on import. You will delete the old data prior to rein porting it. Just be careful of any possible delete related record settings in the relationships graph.
  7. Yes, Custom Menus, Custom Functions, and Debugging are critical IMO.
  8. Your solutions are always so simple. Thanks Comment! At least my 2nd shot at it did not mark records. LOL
  9. After looking again, I remember looking through the documentation before and being a confused on the Local account options once I started to really dig in to the instructions beyond the summaries. After a quick search however, I found this helpful info from Soliant which is a bit easier to follow. http://www.soliantconsulting.com/blog/2009/02/using-local-os-accounts-for-filemaker-external-authentication When using cloud based FM servers, is this is even an option?
  10. A cursory check of Scribe documentation seems to indicate that it uses the newer .xlsx format only and not the older .xls format. The error seems to indicate it wants a .xlsx formatted file. Maybe it is the name of the file suffix, or you are modifying a .xls file with .xlsx file attributes which is causing the error?
  11. UPDATED! This was a trick that we used to be able to use in FM 11. Unfortunately this technique no longer works now since objects do not render outside of the container they are a part of. I suspect this was in preparation for WebDirect so that things would have mirrored behaviors between Client and WebBrowser. You can accomplish this using a looping script to capture the ID of the first record for each break and store it in a global variable. In FM12 you can then use conditional formatting to change the text color to 'hide' it. In 13 you can actually hide the object completely. The calc used to hide the data would be: IsEmpty ( Filtervalues ( $$ListToSearch ; MyTable::RecordID )) Now as for how you would accomplish this in your script: Set Variable[$$ListToSearch;""] SortRecords[Restore;NoDialog] (ClientID;Project) Go To Record/Request/Page[First] Loop If [ isempty($ClientID) or $ClientID ≠ MyTable::ClientID ] Set Variable [ $ClientID ; Value:MyTable::ClientID ] Set Variable [ $$ListToSearch; Value:List($$ListToSearch;MyTable::RecordID) ] End If Go to record/Request/Page [Next;Exit after last] End Loop
  12. FileMaker uses the "!" as a means to find duplicate entries in a single field, but what you do with this simple functionality is another matter entirely. Location of duplicates can be a bit complex depending on how exact or fuzzy you want your results to be. Duplicate searching in filemaker can only give you exact matches, so misspellings or sounds like become issues. You should look into using a SoundEx custom function (check brian dunning's website) to assist with this process to get a 'sounds like' type of phonetic match if you really want it to be more powerful. As for how you collect the results of your searching, you may want to dump the IDs into a temporary table tagged with the user account so you are only storing 2 pieces of data. There are fancy techniques to store results in a global variable so that the data is not stored physically but lets keep things simple for the purposes of this post. Doing it this way, you can present the user with a layout of search results. Just make sure you do a cleanup of the records when they make a selection or choose an action. And just in case they loose connection to the server for some reason, make sure there is a search that occurs up at the very beginning of your script so that it can do a cleanup in case there are records still out there.
  13. This is why I love this board. Nothing but good happens when knowledgeable people come together to share information. I will look into this option more. Thanks Wim!
  14. Instead of hiding the toolbar, use custom menus to take control of the Delete Record menu command which in turn will also take control of the delete toolbar button. The menu can be pointed to a script that you write to take complete control of the process. Modifying the privilege set should also be done as Wim describes so that more clever people cannot find a way around your UI to do things they should not.
  15. You could use a layout script trigger instead: onRecordCommit. This could fire a script to see if the record contains something which marks it as locked. If so you would issue a revert record script step to prevent the save.
  • Create New...

Important Information

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