Yes, as long as you have full admin access you can continue to develop your solution after it has been hosted on the Server without any issues.
What means 'customize' in detail?
You can customize a solution that's served by FMS, You can limit access, etc - You can't remove admin access permanent - but when You want to alter a solution after deployment, that would be no option
You access the solution histed on FMS with Your copy of FileMaker or FileMaker Advanced - similar to a local version. Same possibilities..
Orlando says "you can continue to develop your solution after it has been hosted on the Server without any issues."
Markus says "when You want to alter a solution after deployment, that would be no option"
What i mean specifically is some changes to layouts, adding more layouts and in rare situations, maybe
adding more tables and table occurrences with being careful not change the original tables relations to not break the db. Possible or not possible?
Thanks a lot for your help.
2 of 2 people found this helpful
Yes completely, Adding, editing and deleting layout, tables or table occurrences are all possible when your file is hosted on FileMaker server, as if it was local.
I do 90% of my development on solutions that are hosted on FileMaker Server and it works great, with the added benefits of being able to schedule backups to run while I am developing, so no need to stop working and backup your work.
with a runtime, You can remove the admin access - this can't be done on a 'normal' FileMaker file in that sense (You can limit client access, no problem)
But if You want to customize after deployment, removing admin access would not be a solution, in either way
2 of 2 people found this helpful
I would add the caveat that, if the file is hosted on FMS, and users are accessing the databse, whilst you are making changes, then you could run into issues whereby a change to the databse stucture or a field definition/calculation cannot be commited because a record that is making use of that field/calculation is in use by a user. You will either have to wait until or ask the users to come out of the record/databse whilst you commit the change to the field/table/calculation.
Or i can make it inactive and users will no longer have access to it, and show them a message " The system is under maintenance "
Thanks a lot for pointing that out.
3 of 3 people found this helpful
What markpelleymounter mentions is incredibly important. If you modify the schema of the database while users are actively working in it, those users may run into errors like table locks and layout locks. The 300 section of the FM error codes deals with those:
It is very tempting to change a live solution but keep those in mind and code defensively. If live development will be done then check for those errors at all crucial parts in your code (new record creation, layout changes,...). It's a fair amount of work but the only way to make live development safe from the perspective of data & workflow integrity.
And even if you don't lock anyone out (because you aren't making that kind of change), you can still "surprise" your user with the new changes. Try to be incremental and communicate ahead of time with your users if some part of their typical workflow is going to change as a result of your work.
When adding a new small feature such as a button or portal to a layout and I need to test it before I let others actually use it, I'll use Hide Object When to make it invisible to all but [Full Access] users. Once it's ready for use, I inform any affected group of users, sometimes by sending them a demo video before removing the "hide" expression.
I think people are missing your question.
In this situation I work locally and when I am ready to update the server:
The service needs to be stopped or the files closed.
Backup the server files to a machine with FMP.
Open your new files and import the server data into your new files, then close and copy the new files with the current data back to the server and re-start the service.
Small change or big change with new fields and/or files, Done.
No we are not missing the question. John is asking whether change can be made by NOT going through the steps you outline. With larger solutions, it can take hours, even days to import all the data from one copy of a file into a newer copy, even if only an hour, this is an hour where you have to make the file unavailable to other users and that isn't always an acceptable delay.
And keep in mind that a data separation approach can also be used as a way to minimize the need for importing data from one copy of the file into an updated copy of the same.
You may need to work out the steps of what you need to do on a copy (it also may reduce the amount of time to make changes) and then do them on the live file.
i.e. write a script and depending on if modifying (copy and paste) or new import it.
Yes! I do that often. Not only can I work out the new changes on the off line file, I can then test them in ways that modify data that would not be acceptable on the live system as I would be introducing errors into my data.
Ways to move the change from the test copy to the live:
- Script steps can be copy/pasted.
- Scripts can be imported.
- Custom functions can be imported.
- New tables can be imported
- Field definitions can be copy/pasted imported.
- And if you have redesigned a layout, but the underlying data model, scripts, value lists are the same, you can delete all layout objects from the target layout, then copy/paste all objects from the source layout in the development copy.