I’m always getting questions from FileMaker Pro users - “Should I migrate to Servoy if I’m using FileMaker?”
In general: I tell them “NO!”
Why?
FileMaker and Servoy are two completely different animals - and they really have very little in common - other than they are tools to create interfaces to a database.
Having said that: If you have a FileMaker database that is 1+ GB in size, or you have more than 500,000 data records, or you have 25 or more users, or you want to roll out new revisions of your solution NOT after 5:00pm (or on weekends!) because you have to import your data), or you have run into stability and scalability problems (which you will if you meet either of the other criteria) - then YES, you SHOULD migrate.
You will be able to apply about 60%-80% of your FileMaker knowledge directly to Servoy (click to create a form, click to add fields, CTRL+F for finds, CTRL+N for new record, etc). The hardest part about taking on a migration are:
- Documenting what your current solution does
- Forgetting about the “Workaround Pro” ways of doing things
- Trying to make things more difficult than they are (in Servoy)
- Coming up with a migration plan
Let’s take a look at each of the issues in a little more depth:
Documenting what your solution does
In order to migrate out of FileMaker to anything else - whether it is Servoy or not - you need to have a good grasp on just what it is that your current FileMaker solution is doing. This means that you need to print out all the screens you want to migrate (in both Layout and Browse Modes) and then look at each screen to determine the fields you need to do data entry on, the fields that are calculated, and what each of the buttons does. You will also need to go through and write down all the validation rules (unique, auto-enter, lookup, etc) that you have.
Once you’ve done this - you will have a better idea on what you will need to migrate and how big of a job it is going to be. If you’re like most FileMaker developers - your solution has grown “organically” over the years (READ: no spec, no documentation, worked on by 15 different people - all with different levels of skill). If this description fits - then it is ESPECIALLY critical that you go through the documentation stage! If you don’t you’ll be sorry. Trust me.
Forgetting about the “Workaround Pro” ways of doing things
Because FileMaker doesn’t have any events, and you can only trigger actions based on buttons - you have get *really* “creative” with scripts, calcs, container fields, etc. to make your interface “look like” it’s interactive. Let me just ask you this: How many global repeating container fields with a calc and self-join do you have in order to make a “button” appeared to be dimmed out? If you know what I’m talking about - then you will have a *harder* time migrating to Servoy than someone who doesn’t.
Why?
Well, that means that you’re a “workaround expert” - and you have trained your mind at trying to look at the most convoluted way possible to achieve what SHOULD BE “easy” tasks. This “thinking” is probably going to be the biggest change for you in working with Servoy. In Servoy, you can just say: elements.myButton.enabled = false. This will make a button appear to be “dimmed”. Likewise: elements.myButton.enabled = true. This makes a button appear to be active.
No global repeating containers. No “pictures” of buttons. No relations and calc needed.
Trying to make things more difficult than they are (in Servoy)
In Servoy you can sort related data by saying: relationshipName.sort(”field1, field2, field3″). You simply pass the function a list of fields to sort by - and you’re done. You can build the list dynamically, store it in a variable (like a “global” field, but it’s not a column in your table!) - and then use that. You can really “show” and “hide” objects, portals, fields, labels, tab panels, etc. You can dynamically change the location of all those objects, programmatically at runtime. You don’t have to use tricks. You don’t need to make a “constant” self-join to show all records. You don’t need to remember what the hell “table occurrence” to use, or what “context” you have to use to run calculations in, you don’t have to buy a plotter to print out your relationship “graph”, etc.
In short, you’re your own worst enemy. Servoy does things in a simple, straight-forward way. Sometimes learning that causes frustration because the way you’re “used to” doing things simply won’t work in Servoy. Easy = good. Simple = good. Servoy = good.
Coming up with a migration plan
Once you have your documentation of your existing solution done (DO NOT SKIP THIS STEP!) - you can then create a reasonable plan for creating a data model; planning what screens and reports will “make it” into the new solution; looking at all the value lists, relationships and fields to make a list of “common” elements; decide on an overall look and feel for the application; etc.
Once you’re at this point - then you need to BUILD A SCREEN OR TWO in Servoy. Get used to the tool so you have a better idea of how it works. You’ll discover because you have events in Servoy, and very power control over all your interface objects - you can build the type of application that you can only “dream” about using anything else.
PLUS, you data will be in SQL. Any SQL database you want. No more being “slow.” No more waiting. No more coffee cup icons. No more importing into clones. No more recovery. In short - no more bullshit.
I’m working on a new white paper that will go into more details. If you would be interested in getting a copy when it’s done - drop me an email with you name, company and email address with the subject line beginning with: [WHITEPAPER]. I’ll email it to you when I’m done.
Thought for the day: Migration may be painful, but staying with a f**ked up system is WORSE!
