Rename Export to create a new or template solution

[megaquests]

is it possible by exporting a solution to rename it and then import it again as a template solution or as a different solution all together.

the idea being to avoid having to recreate the whole solution again from scratch when much of the functionality needs to be the same.
and hopefully saving weeks of work.

im sure this question must have been asked already... i had a good search on the forum before posting but i could not find anything.

is it something planned for future or is there a way to do it already?

[pbakker]

When you export a solution and then import it again, you can specify the name by which you want to import the solution, thus basically creating a copy of the solution. Is that what you mean?

Paul

[Harry Catharell]

Hi,

You should be able to do this from both sides of the coin already using :

1) Repository -> Export to File
Here you can rename the exported solution to be whatever you want
Thus you could export a solution to a file called 'template.servoy'

2) Repository -> Import
Here you can choose to import a solution using a completely different name
Thus yoiu could import your 'template.servoy' solution as 'client_????' each time you import it

Whether this answers all your questions remains to be seen.

It can certainly allow you to duplicate/rename solutions and start from a template base but it will still be pointing to the same DB server.

Thus you may also want to think about the need to duplicate your backend database and then set up a new connection to it to then really separate your different solutions !?

Just another thought

Cheers
Harry

[megaquests]

It can certainly allow you to duplicate/rename solutions and start from a template base but it will still be pointing to the same DB server.

many thanks. thats nice to know that there is a method of creating some kind of template rather than starting from scratch on a big solution.


do you happen to know if its possible to syncronise the data of an exported solution if you do dont keep the same back end database. then again if you dont keep the same back end database i dont suppose servoy is capable of duplicating the database design on another machine or is it.

thanks for your help

[automazione]

i dont suppose servoy is capable of duplicating the database design on another machine or is it.

As usual Servoy will surprise you: uploading/upgrading a solution will add any new tables or fields to the taget server for you...with no problems... (of couse will NOT drop the tables or fields no more used!!). As Cusick says... with Servoy YOU'VE GOT THE POWER

[a.mariottini]

It would be a great thing if Servoy could also drop fields and tables when importing (with an option of course).
It is very usefull when the the database is in exclusive use by the solution and there is no need to acces it form outside Servoy.

[Harry Catharell]

Pardon me, Andrea, but what do you mean by 'drop' fields and tables ?

Do you mean remove/delete or something else ?

Harry

[a.mariottini]

Delete

[Odysseus]

I am a bit amazed not seeing a warning about letting Servoy "recreate" your backend tables.

It is my experience that letting Servoy recreate the backend tables introduced subtle changes in the new table that rendered the import useless.

Since I'm not doing this anymore, I don't remember the problem happened with 2.0 or 2.1 but is was on working with iAnywhere backend.

The problem I noticed regarded foreign keys. The original BE Database was developed through Sybase Central. Foreign keys were defined in the "foreign keys" tab of the Central Interface. Defining foreign keys this way permits ASA to "understand" the relationship between the two tables involved. This implicates that you can write queries like "select * from customers join on invoices" WITHOUT specifying the join parameters. This works very well from within Servoy.

When you export this as a solution and then import it on another Servoy Server you CAN let Servoy recreate the db. However all foreign keys are defined as "normal" columns ( so the backend db no longer sees them as foreign keys) breaking all your queries that are based on the "automatic" join functionality.

Just thought I should share this experience. ( Found out the hard way in about 10 minutes before the presentation began )

On the possitive site : this forced me to run the solution over a GSM with GPRS. Worked flawlessy with a speed that was not to bad (remember your 28800 supra modem days )

HTH

[megaquests]

thanks for the warning Odysseus..

to make it more fun our main solutions are in a remote SQL server repository and back end.
i was curious to see if i could export from those solutions and import into a servoy repository and back end running on sybase on a different machine

It is my experience that letting Servoy recreate the backend tables introduced subtle changes in the new table that rendered the import useless.

were you able to go in and fix the subtle changes? and if that is the case does it still not save you a lot of time?

[Odysseus]

were you able to go in and fix the subtle changes? and if that is the case does it still not save you a lot of time?

Of course I could have done that: Recreating the foreign keys (with different names), looping over the records, copying the values from old to new, delete the old key, rename the new key to the old (deleted) key and this for every table. No when you write it out like that, it would have been a terrible timewaster.

Way to go is use the backend manipulation tool (Sybase Central) to recreate the db and import the data that you need through the backend tool or just copy the dbfile. Way faster.

I must say that I hesitated to mention this, as it could have been my inexperience with servoy that made me do something wrong.

Gained more experience since , and I don't think I made a mistake now. So now I think Servoy should warn for this kind of behaviour even more since iAnyWhere is the default DB engine now.