Hi all,
I have a module using 3 tables.
When I reuse the module, the forms still point to the original tables on the original server – I need them to point to identical tables on a different server.
How do I override the server/table of a form?
I would expect there to be some mechanism like o the one to override the style of a form…
I’m a bit surprised noone has come across this problem…
I guess I will have to set up multiple servoy-repositores on my computer to so I can reuse the modules without getting the data muddled up…
You can change the “server” property on each of the forms in the module (although not “automatically”)
OR - you can change where that connection is pointing in Edit → Preferences → DB Servers
OR - you can use a second repository as was suggested.
Hi Bob,
I think I will go for the second repository method, or avoid putting forms in the module… As bugs get fixed and the modules get more advanced I want to be able to ‘upgrade’ other projects with the latest version of the module.
Can’t do that if I start changing the forms.
Here’s a tip for you - this is what I do:
Rather than having two repositories - I have multiple copies of my “servoy.properties” files that point to different databases with the same named connections.
For example - I make a copy of my existing servoy.properties file and put it in a folder called “local repository” - then I launch Servoy and change where the repository is pointed (and/or other connections). Then I quit Servoy and and put a copy of that servoy.properties into a folder called “remote repository”.
Then, when I want to switch back to local stuff - I simply copy the servoy.properties file that’s in the “local repository” folder and - instantly I’m looking at the local files.
It works really well - and is simple to do.
Hope this helps.
bcusick:
Here’s a tip for you - this is what I do:Rather than having two repositories - I have multiple copies of my “servoy.properties” files that point to different databases with the same named connections.
Hi Bob,
I’m already using Edwards brilliant tip on Servoy Magazine a while ago:
http://www.servoymagazine.com/home/2005 … run.html
This works very well
I have half a dozen properties files are with names like
Servoy_clientnamehere.properties
For each one I have a Servoy app called
Servoy_clientnamehere
Have a row of Servoy’s in the Dock 
[wish1]If I could only copy and paste forms between them[/wish1]
[wish2] with all scripts intact…[/wish2]
[/list]
My $.02: changing the server property of a form is something you basically never want to do. Unless you like changing all the relationships and calculations the form’s table is involved with as well.
Good practice for server names then is to use solution oriented names. Avoid using the name of say one of your clients as a server name! Microsoft probably wouldn’t appreciate buying a Servoy solution from you with the server property named “apple_comp” listed on dozens of forms.
Take it from me, changing the server name on even a few forms can be a royal pain. If you must do it though, I have a handy checklist for you
Hi David,
david:
My $.02: changing the server property of a form is something you basically never want to do. Unless you like changing all the relationships and calculations the form’s table is involved with as well.
I fully agree.
david:
Good practice for server names then is to use solution oriented names. Avoid using the name of say one of your clients as a server name!
:-S I do custom solutions, so I use the client name as server name.
When I start a new project, I have to recreate forms by hand in the new solution. Very tedious when 80% of my screens are identical, all scripts are one or two lines calling generic functions in my modules with different parameters.
My modules contain mostly abstract code, at startup I initialize global variables with the current server name and database type (currently Mysql or Postgres) – this works very well.
swingman:
I do custom solutions, so I use the client name as server name.When I start a new project, I have to recreate forms by hand in the new solution. Very tedious when 80% of my screens are identical, all scripts are one or two lines calling generic functions in my modules with different parameters.
Is this faster than importing an existing solution under a new name and chopping out the 20%?
david:
Is this faster than importing an existing solution under a new name and chopping out the 20%?
Good idea! I could set up a template project, in the same way as PostgreSQL has template1. The template would have one example of each of the types of form.
A cool way to utilize a template is to set it up as a module. For each form, set up your basic methods as global methods, not form methods.
Even though you cannot enter edit mode on a module form (so copy and paste of elements is out of the picture), you can duplicate the form into your current solution.
When you duplicate forms, form methods are not duplicated but global methods are. Consequently, I set most of my house keeping methods as global methods. Saves a lot of time not having to duplicate form methods and re-attaching to objects.
After duplication, all you have left to do is change the table name and modify the fields on the form to the table you want to use the form for.
You can use this method to bring in forms from as many different solutions as you want. When you’re done, delete the module.
Again, I highly recommend generic database connection names! This way you can use portions of many solutions to build a new solution and you won’t have to rename database connections.
FYI: I’d be interested to see an example of how you set up your methods. Sounds like a unique solution to me. Tip on Servoy Magazine perhaps?
Cheers
david:
A cool way to utilize a template is to set it up as a module. For each form, set up your basic methods as global methods, not form methods.Even though you cannot enter edit mode on a module form (so copy and paste of elements is out of the picture), you can duplicate the form into your current solution.
Cool. That also means I can temporarily add anoter project as a module to copy forms across
david:
When you duplicate forms, form methods are not duplicated but global methods are. Consequently, I set most of my house keeping methods as global methods. Saves a lot of time not having to duplicate form methods and re-attaching to objects.After duplication, all you have left to do is change the table name and modify the fields on the form to the table you want to use the form for.
For each data type (typically a table) I use:
Six of these are 2 lines or less of code.david:
FYI: I’d be interested to see an example of how you set up your methods. Sounds like a unique solution to me. Tip on Servoy Magazine perhaps?
I will be at Servoy World, so we can discuss this.
it would probably have to be a series of articles 
Thanks for the insight, David.
Definitely sounds interesting. How people are structuring Servoy applications has hardly been addressed. I’ve switched half a dozen times myself in the last three years due to my learning curve and new Servoy features constantly coming out. Remember when we couldn’t use a non-related form in a tab panel? Now we have modules. Craziness!
Servoy Magazine is sponsoring a breakfast at Servoy World. If we don’t cover everything at that time there is always beer time…