There are many good reasons to use development standards when building FileMaker-based database systems or when doing any computer programming. You’ll examine a few here, even though you might think some of them are obvious.
Consistency Is Key
You’ll be surprised how quickly the reason for the existence of a particular script in ScriptMaker or what a certain field is for can escape you in a complex database system. Sometimes you spend months developing one part of the system and get it to the point where it works well enough that you don’t have to touch it again for months.
Then, later on, when you have to go back to that particular database and want to add something to a script or re-code a certain complex calculation, you want to be able to know right away what field does what, and where to find the fields, scripts, layouts or value lists (and so on) that you need to get the job done without a hitch. Thus, if fields are always named a certain way, scripts are always arranged in a certain order (and liberally commented), and layouts are always organized and named in a standard fashion, you should have no problem returning to your work or anyone else’s work that uses standards to determine in no time what was done and why.
Being Nice to Other Developers
Another good reason to use standards is that there may be a time when someone else, either within your company or outside of it, will need to look at and understand your code. Sometimes it’s because you’re training someone else or you and another developer would like to work on the same database system at the same time. Sometimes it’s because you’re going on vacation and someone needs to add an “emergency field” to a database. Sometimes it’s because you’ve just recently taken on a bunch of other duties and you now need to farm out the database development to a subcontractor.
In any case, others should be able to easily understand what you were thinking and where to find what they need in the database system. For example, most people who have developed only a few FileMaker database will understand that gCompanyID is probably a global field and c_MeaningOfLife is most likely a calculation field.
Web, ODBC, SQL, and Other Compatibility
If you ever plan to share your FileMaker databases on the Web or integrate your FileMaker database system with an external application using ActiveX, ODBC, JDBC, XML, or some other industry standard protocol/language, fields and layouts should be named in a particular way. ODBC and Web URLs, for example, don’t “do” spaces or so-called high ASCII characters.
If you know which characters you should and shouldn’t use before you even begin building a database system (whether or not you will ever integrate it with any external application, Web site or data source) you won’t need to worry about re-coding or extra coding later on.
This one just makes sense. If you never have to ponder over how to name or organize all the stuff in your database (“I’m creating a new calc field; should I call it c_Invoice_Total.ckp or cInvoiceTotal?”) you’ll get the work done faster.
Not to mention the fact that you can create a template database with all the default stuff a database should have (like a constant field, a bunch of pat navigation scripts, a standard set of value lists, and so on) from which you can start building every database in a database system. This way, you don’t have to reinvent the wheel for every new database that you want to add to the system.
Also, if all databases are based on the same standard template, you’ll always know where to find things, like where all of your button connected or navigation scripts are (and under what heading), for instance. Too, if you ever import scripts from one database to another, if many of the standard fields are named the same in the source and target databases, it is more likely that you’ll do less respecifying of each imported script due to the fact that many of the fields will already be matched up by name in the target database.
File Maker Related Interview Questions
|Management Information systems Interview Questions||Software Engineering Interview Questions|
|File net Interview Questions||Data analyst Interview Questions|
|Hadoop Distributed File System (HDFS) Interview Questions||Linux File Systems Interview Questions|
|Excel Data Analysis Interview Questions||Asp Dot Net Database Interview Questions|
File Maker Tutorial
Getting Comfortable With Filemaker Pro
Your First Database
Records And Data
Developing Relational Databases
Harnessing The Power Of Complex Calculations
Securing Your Filemaker Pro Databases
Sharing Filemaker Pro Databases
Taking Data On The Road
Filemaker, Odbc, And Sql
Filemaker At The Center: Emulating Or Integrating Filemaker Pro With Other Software
Filemaker Pro Plug-ins
Filemaker Pro Development Conventions
Designing, Est Imat Ing, Planning, Developing, And
managing Filemaker Projects
Filemaker Developer, The Developer Tool, And
Developing Commercial Solutions
Web Publishing With Filemaker Pro
Filemaker Pro Unlimited, The Web Server Connector,
And Advanced Web Technologies
Applescript Automation Of Filemaker Pro
Activex Automation For Filemaker Pro
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.