Large FileMaker 7 & 8 Conversion to Servoy

Classic Servoy
1

We currently run 5 FileMaker 7 Servers with around 200 databases. (built old style with 1 table per file) And 1 Server with 6 FileMaker 8 Databases.(build relationally with multiple tables per file)
Recently, we have been wanting to add more functionality to our solutions, as well as to store more data, and FileMaker it just getting too slow, and we are getting tired of work-arounds. We use dual G5 1.8 GHz towers, and 2 G5 dual 2Ghz XServes for the servers. We have about 150 Clients, with about 90% running Mac Mini’s with 512 of ram, and the rest Windows XP SP2.

So, we are seriously looking at converting over to Servoy. We have an IT Team of 5 developers, and 3 of us are experienced with formal relational database design and theory, and Java. So, we want to do it in-house.

I have read a lot of documentation are articles on conversion (listed below).
So, I have 2 questions.

  1. Is there any program out there to automate the converstion? I am aware of FM|Port at http://www.suitesync.com/fmport/ but it only supports FileMaker version 6.
  2. Will I loose ANY features if I switch to Servoy? (ex. spellcheck)

Here is some helpful information I have gone through so far:
FileMaker and Servoy Comparisons:
From FileMaker Magazine:
http://www.filemakermagazine.com/module … le&sid=479
From Servoy Magazine:
http://www.servoymagazine.com/home/2004 … lemak.html

Step-by-Step FileMaker to Servoy Conversion Process:
http://www.clickware.com/servoy/fmp_tutorial.htm

Servoy Documentation:
http://developer.servoy.com/docs/gettin … mp_dev.pdf
http://developer.servoy.com/docs/Servoy … ideFMP.pdf

I appreciate any help.

2
  1. Is there any program out there to automate the converstion? I am aware of FM|Port at http://www.suitesync.com/fmport/ but it only supports FileMaker version 6.
  2. Will I loose ANY features if I switch to Servoy? (ex. spellcheck)
  1. I think there is another tool out there whose name escapes me that does conversion of FM files to an SQL backend at least. My feeling though is that you would really be better off staying away from anything like that, especially if your solutions are as complex as it would appear they are from your description. My main reason for saying that are twofold:
    A) You will learn so much more and ultimately have a much better system if you develop it from the ground up in whatever your SQL will be and Servoy. You will have your list of fields and scripts within FM of course and you can print out those out with FM developer which will help keep you on track. But a lot of the time it will be better to NOT think in terms of FM. From your description it is unclear whether all of you or anyone has much experience with SQL databases. If you don’t, though, then I think it is even more important that you go through the process of creating the SQL databases, rather than just ‘convert’ your FM files, in order to learn more about them. It is good to have the relational theory knowledge but to build, run, maintain and ‘tweak’ an actual SQL database it is best to get as much knowledge from the ground up as possible.
    B) For a complex solution, I think you actually will be much faster NOT doing a conversion but rather starting over from scratch. It will be much slower in the beginning of course but ultimately that time spent really learning Servoy will accelerate the development and make it better than ‘fixing’ a conversion. There are so many things in development in Servoy that are SO much faster than FM once you learn how to do them. Again I am speaking only about complex solutions and ‘conversions’. I still use FM 6 for simple, stand alone solutions where I want to present related data to one of my MD’s in the department. In that case I can just send the MD the related files, they can keep it on their desktop machine and that data never needs to be shared with anyone else.

As to your second question about losing features in Servoy vs FM, off the top of my head I can’t think of anything (there is actually a spellchecker function within the method editor although I haven’t used it - we don’t have any need for it - so I can’t really comment much about that particular function). Over all my whole experience with Servoy has been so good and so much fun - even in the early days when I would really struggle with something. A large portion of that enjoyment has come from this, the Servoy Forum, by the way! What a novel idea - have a list that people can contribute to, ask questions, make requests and complaints and actually have the developers themselves respond to. Might be something in FM’s plans for next century…

3

Thanks for your response. 4 of the 5 of us know SQL very well. We plan on using mySQL as the backend for servoy. We already use mySQL for some web applications. 3 of the 5 know Java.

You make a good point about the support with FileMaker. We even paid for the premium support, and Level 1 isn’t very helpful. I’ve been complaining a lot to them, so recently I’ve been getting some Level 3 support. The problem with all of their support however is that none of them have real-world experience. I explain a situation to them, and they just respond saying they have no experience with that and are unable to give any advice. So, its like pulling teeth to get to Level 3, and once you do, they can’t help. Next, they are supposed to be sending out an engineer to our site. It that still doesn’t give a resolution to our problem, we have no choice but to switch.

4

One thing that FMP developers tend to dislike is the absence of the “notebook” UI that allows navigation through the entire dataset. Check out the following:

http://forum.servoy.com/viewtopic.php?t=4753

Truth is we tend to use more of a “web” centric approach to our Servoy UI. It is a search based approach, rather than an approach that says “here are all your records”.

The fact that FileMaker “owns” the database makes a difference… FileMaker knows when certain events take place in the database… Servoy does not. As many databases in a corporate environment get inserts, updates and deletes from many sources, not just a single biz app, Servoy is not always aware of these changes (and can’t be expected to be).

The bottom line is that Servoy is different… appealing to a different audience, really. And when developing in Servoy you must think really differently, much as FileMaker developers had to learn to think differently when moving to FMP 7/8. IMHO it is only when you understand how a product thinks that you are able to develop systems properly.

As some know I’ve been working on, and am currently finishing, a training course in Servoy called “Servoy Essentials”. It has required LOTS of effort… not just in learning about Servoy, but also learning more about the underlying database application, object oriented software, Javascript coding and more importantly, how and why Servoy does certain things.

In the end, the more I understand about Servoy, the more brilliant I believe it (and its designers/developers) really are. They have made some incredible design decisions, and we benefit from those choices.

However I can’t emphasize enough… it is different than FMP. It is more difficult to learn and use. If your view of how database systems work is limited to FileMaker, you have to learn about a whole other world. You must unlearn much, and learn a whole new world.

Finally, you do not want to simply convert your FMP app to Servoy. That type of thinking will result in a malformed Servoy app. Certainly many of the business rules and processes, reports, data flows and use cases will be the same, but the way in which you get there, by necessity, will bear no relationship to where you started.

Cheers,

Rich Coulombre

5

As a developer, loosing the rolodex-like record browser wouldn’t bother me…however our users would throw a fit. Its one of those things that I can’t really understand why they use it, but it is like a security blanket for them.

I know there will be some issues with a straight converstion from FileMaker, but I really need it in my situation. Here is the whole situation…

For 10 years our company has been running on FileMaker. The deveoper at that time was not familar with normalization of data. So, throughout the years, we have about 200 databases, many duplicates of eachother, then modified and renamed to fit some specific need. Instead of making tables or related databases, the developer created additional fields, example PersonName1, PersonPhoneNumber1, PersonName2, PersonPhoneNumber2, etc.

Since then, our company has been growing pretty quickly. We are at the point where the solutions are running very slow, and getting huge. So, they get archived (the ugly filemaker way, duplicating and renaming DatabaseName2005).

So, a little over a year ago I took over a project to create a new system from the ground up to streamline our process and develop a database system that would last us for many more years. Since we were already using FileMaker, we looked at the new FileMaker 7, which they were selling as a high-powered database management system. We had our doubts, so we went as far as a pre-sales conference call with the FileMaker Senior Director of Field Sales and System Engineering, Steven Gallagher. We explained our needs, and they sold us. At that point we had hired 2 additional programmers (familiar in both FileMaker and traditional SQL databases), and the 3 of us took on the project.

The project was huge, we went through each department and analyzed and made changes to streamline processes, while developing a FileMaker database to mach those processes.

Last month, after spending 1 year developing the solution in FileMaker, we do a load test with our users. The plan was to start with 20 users, and go up by 20 until we reach 100 active users. We got to 60, and it didn’t look good. The solution was slow and unresponsive for large amounts of time. The CPU on the dual G5 2 Ghz was maxing out. We have made changes to the solution and been able to improve speed somewhat, but still not enough. After spending about a month with FileMaker support, we are at the point where something has to be done. The company has been waiting over 1 year for this product…and we need it. Because of our complexity, size and continued problems, FileMaker is going to send a engineer on-site for help, so that is out last hope with FileMaker.

So, if it turns out that we need to switch, and we choose Servoy as the application, we need something to convert quickly, and then we can perfect it over time.

6

Wow, sorry to rattle on so much in that last post..

I’ve been digging through the forum and try to list out some differences. Can someone please let me know how Servoy handles these items differently from FileMaker?

1.Security. We use some standard FileMaker accounts on some databases, and user external accounts with out LDAP server for most other FileMaker databases.
2. Windows. In filemaker, you can pop-up as many windows as you want. You can also make them modal windows (even though it is a work-around).
3. Instant Web Publishing. We have external accounts that use IWP for accessing some data. They are customer of ours, so they cannot download a client and must be web-based.
4. Applescript. Since we are mostly Mac’s, we use the Perform Applescript scriptstep in FileMaker. Does Servoy support it (both out and back in)?

Thanks in advance.

7

1.Security. We use some standard FileMaker accounts on some databases, and user external accounts with out LDAP server for most other FileMaker databases.

You can use LDAP but you would have to create a plugin for that I guess…

  1. Windows. In filemaker, you can pop-up as many windows as you want. You can also make them modal windows (even though it is a work-around).

You can not show more than 2 windows where the 2nd window is always modal. This has been discussed over and over by FM developers as one of the things the user ‘really wants/needs’. It is my experience that the use of tabpanels is so much better than with FM that users don’t bother much once they are ‘on th road’ with their new solution that gives them so much more…

  1. Instant Web Publishing. We have external accounts that use IWP for accessing some data. They are customer of ours, so they cannot download a client and must be web-based.

Here you can go for 3 different approaches:

  1. Create a seperate ‘account’ solution and let the account have the idea he is really special because he can now use a real application (JWS) to add his data.
  2. Use the headless client which you can use via jsp pages.
  3. wait for 3.0 and create you web client right out of the box.
  1. Applescript. Since we are mostly Mac’s, we use the Perform Applescript scriptstep in FileMaker. Does Servoy support it (both out and back in)?

What do you use it for? You can go out without any issue for sure. Not sure for going in here. I guess there are ways to do it. Maybe again via a plugin that captures your data.

In general there is no single solution to answer your questions and maybe doubts. Looking at what you write about your solution and about the experience of some of your developers you will probably be able to write plugins yourself (or let me do it :) ). And for sure you will be happy with all stuff that Servoy gives you.

I agree with John though that you will not be happy in the long run when you try to convert your existing solution 1:1 into Servoy. What you might want to do is create the screens again since you have so many more possibilities with Servoy.
Use a driver to connect to the FM databases and copy the tables to MySQL (should be possible I guess).

Hope this helps a little.

Cheers

8

goldcougar:
4. Applescript. Since we are mostly Mac’s, we use the Perform Applescript scriptstep in FileMaker. Does Servoy support it (both out and back in)?

Absolutely. And creating a new record (or modifying a value in a certain record) only takes one line of AS.
There’s an article of Jan Aleman, on Servoy Magazine.

9

Hi,

I’m coverting a medium-to-large FileMaker System at the moment.
My experience with Servoy from a development point of view is that it can handle any requirement that my customers can come up with.

I have yet to get stuck by any limitation :wink: Between JavaScript in Servoy, Plugins, Beans, SQL and Java there is always a way of getting things done. Pretty awsome.

I do, however, find myself rewriting and rebuilding my code every three months or so as I learn how do to thing in a simpler and better way.

Servoy has many sides;
You can use it in a FileMaker-like fashion without knowing much SQL, or you use SQL for every search, value list and report.

You can write code which is database-independent, or which ties tightly to your chosen database exploiting any useful features of the DB.

…

I think your main problem swiching to Servoy for such a large project will be to get the structure in Servoy right from the beginning modules, reusable elements, forms. Sounds like you already have the skills in your team to design a decent database (mySQL?).

Building all the screens and navigation will be the main challenge.

Good luck,

10

Instead of having to convert all of our databases at one time, if we could figure out a way Servoy being able to lookup data from a FileMaker database, that would allow us to convert the FileMaker databases over time.

For example, if we have a database of company contacts in a FileMaker database, where they each have a unique companyID, is there a way where end users could enter the companyID into a field in Servoy, and it would bring over the companies information, (name, address, etc)?

11

It should be possible. As far as I know you can connect to fm using an odbc driver or Servoy has a built in system in 3.0. I think you should check that…

12

I think David (of DataMosaic and Servoy Magazine) has done some very advanced stuff hooking up Servoy with both FM and an SQL backend. You could check that out. I think the stuff he has done has been because for some reason the FM side had to stay in FM (belonged to a different group or something). If you are going to change the whole thing though I still think you would be well advised to try and break it down (if possible) to individual ‘solutions’ within the overall setup and do one of the individual solutions completely. Then if the FM partial solutions need data from the new Servoy solution, get data out of the SQL back end. That way your (partial) Servoy solution is done and you can disentangle yourself step by step from the tar baby :lol: . That is what we did. The main difference was that we were using FM 6 (didn’t like 7 from the beginning) and I could use the SQL plugin to keep the FM files up to date (which worked very well indeed). I don’t think the SQL plugin works with FM 7 and 8 though. But perhaps the native hookup within FM to SQL works well enough on its own.