Would you do it again?

Classic Servoy
1

Hi,

I currently have a desktop application developed in Microsoft Access, and distribute it via the Access Runtime. I am considering moving/re-writing the app using Servoy in order to move to more open standards and give me easier access to the Web and the Mac market. One alternative, for example, would to move to .Net and use the open source Mono Project. Or some other platform, ie, Runtime Revolution, perhaps.

I wonder if there have been others in similar situations, using Access or Filemaker or something else, and if they consider their move to Servoy to be a success for them. Are you “happy” here? Would you do it again, or would you go to something else?

Any thoughts would be appreciated.

Thanks and have a good day.

Ron

2

We moved our vertical market solution for the insurance industry from FileMaker to Servoy. Our first conversion used the Servoy smartclient. We later converted to the Servoy webclient when it became available. The webclient has fit our situation very well. We needed a solution that we could host and that our users could immediately access without having to install any software. We have been hosting our multi-tenant Servoy solution for nearly four years now with 99.9% uptime. We are very pleased with the Servoy development environment and with the support offered by both Servoy and the Servoy community.

Would we do it again?

Yes, with no hesitation.

Dean Westover, President
Choices Software, Inc.
1-800-873-4757
http://www.acords.com

3

Yes, I would do it again. We went from FileMaker to Servoy.

Of course I would do a better job this time around… hindsight is 20/20.

The product is good, the community is good and I think the tech leaders at Servoy get it in terms of where software is going.

-Chico

4

Hi,

Thanks for your thoughts. Any change like the one I’m considering is kind of daunting, and getting some positive thoughts from others who have done so is a good thing.

Ron

5

The short answer is YES unreservedly - I would however change the approach I took. I came from a mainly Filemaker background and had no experience of Javascript at all and a very very limited understanding of SQL.

In retrospect I would:

  1. I would buy Adrian McGilly’s book on Servoy and use it as a getting started bible
  2. Watch all of the video demos done by Servoy - they are excellent
  3. Pay for a few days 1-2-1 tuition with Servoy or a Servoy trainer specifically especially on the web client
  4. I purchase the majority of plugins from IT2BE and Dr Maison - and depending where you are get a lesson/training from them on how to integrate the components - both provide excellent demos however
  5. I would buy a 10 hour support pack from either IT2BE or Servoy to give you help on demand over an above the forum
  6. I would install 2 versions of developer one with examples and demos by the likes of Servoy, IT2BE and Dr Maison and a second with your own solutions mixing them becomes confusing
  7. Backup the workspace regularly if it dies your starting again !!

Hope that helps…
Gordon

6

RonG:
Hi,

Thanks for your thoughts. Any change like the one I’m considering is kind of daunting, and getting some positive thoughts from others who have done so is a good thing.

Ron

Ron - like you we came from an Access App situation. Our development has been significantly slower than any we did in Access, and even though we had a brief and disastrous foray into .NET, the development for us (because of our VB / VBA background) was faster than it has been in Servoy (using some dev tools such as Radvolution etc).

As Gordon suggested there are a number of steps you should take before starting your development - and I think he got the list almost perfect - we did almost all of that including the one-on-one training etc. One thing I would not do is use external plugins unless you find them absolutely essential - perhaps its just us, but we want to minimise external code as much as possible to minimise potential problems along the line - there are enough problems just figuring the way through Servoy.

One thing I would do differently now is take up Servoy on their development offer and allow them to do the basic porting of your app design (with you as a part developer of course) and get it running in the shortest possible time. If we had done that I guess it would have saved us £30k - £40k over the last 18 months of learning on the job!

Overall I think Servoy is the right way to go. The potential for web and smart client development, in-house and remote server deployment is fantastic, though I have to say, so much of our app will have to remain Smart client only because of limitations in functionality and speed (though we will hopefully work with Servoy on the speed issues soon).

All in all Access is significantly easier to develop in and can create much more functional UI’s (I’m thinking grids here BTW before I get a flame roasting). We found Access easier mainly because the use of Servoy is not properly documented, you cant go out and get a couple of books to help you transition, so apart from Adrian’s manual (which is excellent, but not up to date AFAIK) all you have is a reference WIKI (best we’ve had since we started - but few examples of how to use the functions / code in real life conditions) and the forum. Servoy expect you to search the forum for previous posts on your particular issue, to study and learn from. Not the ideal learning system by a long way. There are several Example Solutions also - to dissect and learn from - but again figuring out what an app is supposed to do then dissecting it is not the best learning experience IMHO.

Unlike in VB/VBA where you could get examples and how to’s on almost anything - you may struggle to get what you need in your version of Servoy. BTW the forum contributors are the best I’ve come across anywhere. If you ask the question you’ll most likely get it sorted one way or another - though for me I’d prefer to learn and study rather than simply ask on the forum (I’ve done lots of both however - and all contributors have been really generous with their time for us).

JavaScript was also mentioned earlier - and for us learning this aspect of Servoy was both easy and very difficult. Of course JavaScript is simple syntax wise and after a foray into C# it wasn’t so bad a transition for us. However Servoy uses Rhino to script its activity and it’s not really possible to get hold of a JavaScript book and apply what you find to making your app work - JS is usually described in terms of web pages in most tutorials. The hard part is figuring out which Servoy built functions do what and how they should be applied - then the JavaScript necessary to make that work. Your SQL skills from Access development will come in very useful in Servoy though (unless like us you spent most of your SQL time building in the GRID :shock: ).

Would I do it again - that’s a tough question. Starting from scratch with a first app - knowing the lack of documentation and the fact that it wouldn’t get better quickly - probably not!

Now we are in it - and like the potential - I’d say if we had another app to port I’d get with Servoy and use their offer to get the port done quickly and with their in-house staff so you learn with them as you do the development. So in that case yes we would do it again!

Best of luck - doubtless see you here in future! :wink:

7

Gordon and Kahuna,

Thanks A LOT for that input. Very useful information. I’ve taken notes and will be following up on them :D.

It’s especially interesting to have the input of a fellow Access developer. What I’ve researched so far matches up pretty closely with what you’re saying. There is a wealth of information and “cookbooks” on how to things with Access; that doesn’t appear to exist with Servoy. That doesn’t make thing undoable, it will just be more challenging to do the work without as much exposure to the previous work of others. For the amount of time that Servoy has been around, I’d hope that there would be more than I’ve found so far. But, if the forums are as helpful as people have said, that could work out ok. I’m thinking right now that the learning curve is steep, but once a solid understanding is gotten, development can be quicker with Servoy, at least when you take into consideration that one set of code is giving you access to Win, Mac, and Web. The effort to build that in the Windows environment is bound to be longer, at least if Servoy works as advertised.

With a couple of more ducks to put in a row, my plan right now is to go to the May training classes at Servoy in California. Hopefully, that’ll get me on the right path.

Thanks again, guys, Great comments.

Ron

8

Ron

Coming from a varied background (Omnis, Access, FileMaker and VB with MSSQL server) I found Servoy much more rounded in terms of the deployed system, ease of update and rollback of user application versions, ease of scaling, separation of function between client, application server and db server. So much of this is in the nature of the architectural design, which you inherit from the start.

I agree with others in the strength - and speed - of the community here; the responsiveness of the Servoy team; and yet the apparent lack of Servoy resources. In the early days I purchased a full set of the Servoy books on paper – well worth while. There are lots of small examples in the methods pages which are worth close study. They are all there in the sample code editor in Eclipse, I believe, but somehow when seen on paper I realise more clearly that they are there to be studied and used. But you can download these as PDFs from the Servoy website and study them preferably on a multi-screen machine! Seriously, paper is still good.

As with all code, there are so many ways to do things that best practice emerges only slowly as people try various ways of achieving the same thing. We learn by sharing with each other what we find.

My own way of learning was to build very simple apps initially to understand the full development/maintenance cycle; and then to add complexity little by little. And to study and adapt the sample applications.

Getting Servoy in to kick-start development would be a good way to start learning and get somewhere quickly.

9

Hi Richard,

Thanks for your comments. I’ve pretty much concluded that Servoy is going to be the way to go for me and my product line. The question becomes “next steps”…

I’ve got a new version of my product that has been under development for some time on Access97. The plan there is to move from Acc97 to Acc2007 to avoid conflicts with newer versions of Windows and Office, which pop up occasionally. In order to roll that out, I also need to write some software that will convert my customer’s Acc97 data files to Acc2007. I’m figuring there’s about 2-3 more months of work to complete that. And then, go to Servoy.

Or, I could just complete the enhancements under Access97, and go to Servoy. That saves a lot of work, and allows me to market an interim upgrade on the way to Servoy. Figure that would take 2 months instead of 2-3.

Or, I could just do some cosmetic cleanup that’s been needed for awhile, and release that and save the enhancements for the Servoy version.

Or, I could just abandon the Access upgrade completely and go directly to Servoy. Let’s say that I could do that in 8 or 9 months, so, by the end of the year.

The current version is perfectly usable and marketing efforts continue. With the potential to be done by the end of the year, I could be offering a new, updated application available for Windows and the Mac.

I’m thinking right now that the path that appears to make sense is to do the cosmetic upgrades (which are very low risk), and then move the enhancements to the Servoy version, allowing that to be a much bigger “splash” of a release. New capabilities as well as a new look and feel, available for PCs and Macs.

Anyway, I’ve heard enough and read enough to be as confident as I can in making the move to Servoy. Good luck to me :D .

Thanks again to all that have responded.

Ron

10

Ron - one avenue I would explore if I was you (and we came from A97 too - in fact still have it deployed) is to use the up-sizing wizard to transfer your data (I assume you have it in a Back-end / Front-end model) to MSSql. That way you can continue to run your A97 app against it by linking to it instead of the A97 back end, and benefits include being able to use RWOP queries to keep the back end secure just like in A97, and also use the same databases and tables to begin the development of your Servoy model.

Best of both worlds! Any new development you can duplicate in both systems whilst you build the Servoy app, and simply roll it out as a direct replacement when its ready using the self same database!

11

Hi and thanks,

That’s an interesting idea. Off the top of your head, any idea how that would work with the Acc97 Runtime, which I use to distribute the app? And licensing of the db? Oh, and yes, the database is split, as you surmised. The app is aimed at single users right now, and is distributed as a Acc97 runtime app. I wonder if I’d need a MSSql license for each user that buys the software. I think what you’re talking about works well in an internal networked app model (which I’ve actually done in the distant past) using Access as the front end to a multi-user backend database. Not so sure that it fits here, but I could easily be misunderstanding what you’re suggesting.

Thanks again.

Ron

12

RonG:
Hi and thanks,

That’s an interesting idea. Off the top of your head, any idea how that would work with the Acc97 Runtime, which I use to distribute the app? And licensing of the db? Oh, and yes, the database is split, as you surmised. The app is aimed at single users right now, and is distributed as a Acc97 runtime app. I wonder if I’d need a MSSql license for each user that buys the software. I think what you’re talking about works well in an internal networked app model (which I’ve actually done in the distant past) using Access as the front end to a multi-user backend database. Not so sure that it fits here, but I could easily be misunderstanding what you’re suggesting.

Thanks again.

Ron

You can run the A97 app in exactly the same way you do now Ron - just make sure you link to the MSSql tables (probably with an ODBC connector) instead of your A97 tables.

You can use MSSql Express (I think it used to have a different name but essentially its a lite version and only allows 5 concurrent connections - pretty fast though). You can use MSSql Manager (a free utility) to set it up and add permissions etc.

I used to handle licensing by completely locking up the front end with the work-group file - and the back-end can either be completely locked so only your app has the relevant connection user name and password, or in my case, most of the tables were open, but there was one table that contained configuration and license data (checked the No licences before start-up) and that table was locked as suggested above. That gave the client access to his own data if he wanted to use XLS or some other tool to interrogate it, but locked down my app.

This all works in Runtime BTW.

HTH

13

Oh, ok, I think I got it. I’ll look into that. I’m doing pretty much what you’re describing as far as locking up the database front end and back end, as well as license checks.

Converting Acc97 to Acc2007 is turning into quite an adventure, maybe more of an adventure than I want to mess around with. Strange error messages, like…

“The database cannot be opened because the VBA project contained in it cannot be read. The database can only be opened if the VBA project is first deleted.”

I’ve seen references to this on the discussion forums when users try to access databases, but I haven’t found any references, yet, in regards to the conversion of a database.

We’d hate for it to be easy. :-)

Thanks again, and have a good day, or evening, or whatever it is in you neck of the woods.

Ron

14

RonG:
Oh, ok, I think I got it. I’ll look into that. I’m doing pretty much what you’re describing as far as locking up the database front end and back end, as well as license checks.

Converting Acc97 to Acc2007 is turning into quite an adventure

Ron

Ron - from what I understand you cant access an A07 back-end with A97, and to convert an A97 front-end to A07 you need to completely de-secure it, convert it to an AProject (rather than a Db) and then make all of the coding changes from using the old data binding code to the newer ADO code. I’m sure you know all this already - but my point is its a whole load of trouble if I remember rightly from my explorations!

IMHO Much better to cross the back-end to MSSql and keep the front end in A97 til you get the Servoy model done. I found none of the code from A97 would copy paste to Servoy (of course) but the structure and the way I did my coding was pretty easy to rebuild in Servoy in many instances - especially where I use SQL for filtering etc.

BOL

15

Hi,

I’ll be sure to look at that.

As far as going to Servoy, I’ve got the existing application, so in large part, I have the database design as well as the business logic. That is a gigantic time saver right there. I know what my current forms look like, what the SQL queries look like, reports, etc. So, all of that design work is done. It’s a matter of figuring out how to do that in Servoy. I’m considering attending the training coming up in May, figuring that that might give me a good jump start to get going.

Ron