Search Project Mgmt
Search FileMaker Blogs
Saturday
Oct112008

FILEMAKER: Dangers Of FileMaker Deletes

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

There are considerable dangers involved with allowing users of FileMaker files the ability to delete records. For starters, there isn’t any "undo" feature for deleted records built into FileMaker. Once a record is gone, it's time to hope there is a recent backup handy.

Another danger involves the way you can setup your relationships between FileMaker files. In the relationships setup dialog box, you can have related records automatically deleted, when a master record is deleted. Sounds good in theory, kind of like cleaning up after yourself. However, what if those related records were related to others and the delete relationship option as on? To make a long story shorter, this little option can be responsible for deleting thousands of records, all with the accidental deleting of one primary record.

If you are not a student of database relationships, I’ll try to make this as painless as possible. You can have multiple FileMaker tab;es linked together. This allows you to organize your data sources into individual tables, such as Clients, Invoices, Inventory and such. With relationships, you can have them linked together so the invoice file can see or capture information it needs like Client information or Inventory levels. With relational cascading deletes, you could delete a client record, that deletes associated invoices, that deletes associated products, back to associated invoices for those products and even back to associate clients to the associated invoices. So you can see that the cascading relational deletes is not something to take lightly.

YOUR OPTIONS NUMBER 1
Add secured access to your database solution. Set the access of each traditional user account to not have the ability to delete... except the accounts that really need delete access of course. DRAWBACK: Well, no one can delete a record. Your database will quickly suffer from blank and incomplete records. You can put in a field that indicates the user wants to delete a record. Then have a cleanup script run at the end of the day. This is not an elegant solution, but for some short lived databases, it may be a viable option.

YOUR OPTIONS NUMBER 2
Add security access to your database solution. Set the access of each account to have editing capability only in the menu commands. DRAWBACK: Many of the normal menu commands are missing such as FIND, FIND ALL and DELETE. You will need to create buttons on all the layouts that restores the things that used to be in the menu. This also does nothing about the UNDO delete issue.

YOUR OPTIONS NUMBER 3
There are plug-in based utilities out there that will automatically copy deleted records to an archive table when they are deleted. Some of these tools even have restore capabilities that you might be able to implement into your solution. DRAWBACK: You have to distribute the plug-in to all users. You have to purchase the plug-in. You have to do some programming and testing to use the plug-in.

YOUR OPTIONS NUMBER 4
Use custom menus for record deletion because this will allow you to write scripts that handle your FileMaker delete operations in a manner that works for you. This can be combined (to a degree) with any of the above options as well.

YOUR OPTIONS NUMBER 5
Backup all information to an archive file before deleting via scripting. This is done by using a combination plate of the above options. For sets of very key data, you can build an archive file that passes the information to it first and then deletes the master. DRAWBACK: It will take time to pass all the data to another file. Of course, if you are having too many deletes by your users, it’s an indication of other possible problems. You will need to build an archive file for each file you want to do this for. You have to store a lot of extra files / records but you do have excellent recover capability for unintended deletes.

YOUR OPTIONS NUMBER 6
This is a variation of option number 5, instead of writing the information to a backup file for each file, write them all to one archive file and save the information as a text array. This is something that advanced users are familiar with. The idea is that you take a bunch of information from a bunch of records and save it as one calculated text string. Each piece of information is separated by a flag or marker. If this sounds a little like HTML, you are right. Web pages and the elements in them do resemble text arrays. This allows you to save more information in a smaller space. It also offers a smaller performance hit to users. DRAWBACKS: You will need to build an engine that can breakup the text array. You will use this engine when you have to restore deleted data. This option does take some time to setup and modification time can hurt if your database isn’t quite mature.

SO WRAPPING THIS RASCAL UP
As you can see, there are many options when it comes to protecting your FileMaker database against accidental record deletion. None of them are perfect and none of them will make everyone happy. However, one of them ( or a customized combination plate of them) will likely take care of your immediate business needs. Personally, I tend to start at the bottom and work my way up to Option 6.

Unless of course, you know that your database solution will be working in a very dynamic office environment. If the company is going to have a large number of temporary or contract employees doing data entry ... I’d recommend leaping directly into options 5 or 6.

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

Wednesday
Jul092008

FILEMAKER: Creating A Serial Number System

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

Many FileMaker developers create FileMaker solutions that can be used in outside companies and workplaces. In this way, they become software publishers that used FileMaker as their database engine. When the developer distributes a trial copy of the solution, they may want to use a serial number validation or activation system that you find in many commercial software packages ( including FileMaker products ).

There are a number of steps you will need to plan if you want to implement such a tasks. One is that you need to figure out a serial number format. This format has to be obscure to the casual user but needs to have a way to indicate if a entered serial number is valid. This serial number format is usually alpha numeric and consists of 10 to 16 characters. You can include special characters if you like. If you want to make it case sensitive, you will need to use the Exact text function somewhere in your logic. You may also want to avoid the use of characters that can easily be confused such as the number zero and the letter 0 ( 0 - O ).

It may go without saying but valid serial number checking will need to be part of the opening script of the main file. Generally, the developer will want to key the opening scripts and key productivity scripts in all files to the status of a valid or invalid serial number entry. Some operations or navigation may be disabled for missing or invalid serial numbers. You will also want to build in a way to encourage the user to register and enter in a valid serial number.

Finally, you may want to have a way to have FileMaker build you a bank of valid serial number codes. If your product becomes wildly successful, you don’t want to have to spend time doing this by hand. Although as problems go, the ones that come from the wildly successful variety ... usually are the least painful!

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc

Sunday
May182008

FILEMAKER: Security Related Script Steps

From Dwayne Wright - Certified FileMaker 9 Developer
www.dwaynewright.com
info@dwaynewright.com
TWITTER: dwaynewright

Just a FYI that I’m covering (or perhaps by the time you read this, have covered) the script steps that are associated with security account management in my FileMaker Scripting Explored blog. Here is a link to the first script step in discussed, which is Add Account.

Add Account Script Step
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

Sunday
Mar092008

FILEMAKER: Password Rotation

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Keeping the same password for an extended amount of time can be considered a security risk. This is because (and this takes a little time to explain), if the password gets out, the longer it stays unchanged, the greater potential it will be known by more people and the greater potential that one of those people will use that password inappropriately.

Rotating passwords means that you require each accounts password to rotate within your solution(s) on a regular basis. I know of some law offices using FileMaker solutions that rotate all their passwords every 30 days. I have also been in places where the same passwords were used for years and generally known by everyone in the office and people that have left the company.

Now back in the FileMaker 6 days, a rotating password implementation was a royal pain. For those of you that have upgraded to a newer version, rotating passwords is much easier. If you setup your FileMaker solution to use multiple tables in a file and each user having their own account name, rotating password processes are downright easy.

In FileMaker 7 and higher, rotating all the passwords for all the accounts for a privilege set is setup right in the define privilege set dialog box. You simply check the appropriate dialog box and then put in the number of days requirement. This is just another example of the benefits of taking the time to setup your accounts and privilege sets correctly.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.

Wednesday
Jan302008

FILEMAKER: Accounts And Privileges In Multiple File Settings

From Dwayne Wright
www.dwaynewright.com
info@dwaynewright.com

Many FileMaker solutions make up more then one file and sometimes those files need to have the same security settings and sometimes they do not. So you need to remember that making a change in one file will NOT make the same change in another file. You have to open each file individually and change the security settings in each file.

Now ScriptMaker and your scripting skills can help here but they do not extend very far but in many cases it is far enough. You can add and delete accounts, reset the password for a specific account, change the password for an account, enable an account that is not enabled and re-login into the file with a new account.

As you probably know, you can daisy chain scripts, so that one script can call upon another script in another file. So you can script the account setting changes from one file to the next from one master script.

YOU CANNOT SCRIPT CHANGES TO PRIVILEGE SETS OR THE ASSIGNED PRIVILEGE SET TO A CURRENT ACCOUNT. I assume this is for overall FileMaker security reasons and it really is proper this be the case.

So you cannot script the changes of an account to a different privilege set or can you? The answer is you can but not really. You can hard code the setting of a new script created account to a particular privilege set. Using script parameters, you can have dozens of hard coded options to assigned privileges available via script branching. So you can delete an account and recreate it with a different privilege set. It is not pretty but it can be done and is done all the time.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.