Shifting between windows on FMGo is a pain.
You probably need/want to create layouts for Go
In which case, a Go specific file is not such a bad idea.
Without looking at the file it's hard to say exactly what would be best, but it sounds like this may be an older file that has been updated over the years.
Pre-version 7 databases were 1 table per file, so in every system you had multiple files and had to bounce back and forth between to get to the layout/data set you needed. This added some complexity to scripting and had some big limitations.
In version 7 and up each file could contain multiple tables, and the relationships were able to be more complex. You can still keep the older structure with one table per file, but you lose out on the advantages of the new format.
Especially on the iPad I would think it would be much faster and cleaner to have everything in one file, but again I don't see your system or know what you need from it, and there are times that there is an advantage to splitting things up some. As much as possible keeping your main layouts together in a common file would help, but if the data is split up this much it may require jumping through some hoops to get there unless you combined the tables into a common file as well.
Generally from my experience it's a trade off that you have to weigh out, a major overhaul that brings the structure of the system up to newer standards and takes advantage of the newer features vs. no major overhaul and dealing with the speed and complexity issues of the older structure. Eventually most people upgrade and rework the system at some point, but I've also seen systems designed in v.3 still being used in 11 today, but there are generally some quirks with them.
Thank you very much for your suggestion. But for you, having a sole-interface-file, with all tabels out (in 1 or more files), is a sane choice?
this is a quite easy one-man activity management software, with
Having table-file out, on a webfarm for example, and using the only interface-file on iPad and/or on Desktop PC, would give some advantages in term of speed-performaces?
Honestly speed issues can be caused by different things, so it would really depend on what is causing the performance issues, and without looking at the file I can't say for sure, but in general spreading things out would seem to add more complexity and give you more opportunities for speed issues, pulling things together into one file often is going to go smoother than splitting them up.
You've not mentioned whether this is currently hosted on a server, or just used locally, so I am assuming it's hosted. Is it accessed mainly on the local network or offsite?
I am a huge advocate for the single file solution. Here are some of my reasons…
1. Vastly less repetitive developement work, Table occurances only need to be built once. Same thing with any Security settings and Custom Functions. In addition… no need to worry about file references and you can change the file name with no consequences.
2. Easier in hosting environments… There are limitations on the amount of files FM Server can host… As well as a Cost-per-file on many/most hosting servers.
3. Also… ( this is more of an opinion based on approximately 20 years "I started with FM 2.1" using and developing with FM )… I believe there is a greater chance of File damage when a file looses connection with another solution file during data entry. I "personally" feel a single file solution is more reliable than a multi-file solution.
4. Everything about working with FM-Go seems faster and cleaner with a Single File.
5. Easier to visualize as all calculations, relationships etc… are together in one file.
I could probably come up with a dozen more reasons if I had a few days to think about it… But for me it comes down to this… For various reasons I currently have a mixture of Single and Multi file solutions I support and develop. I CONSTANTLY regret building the Multi-file solutions as they are and wish I did them as Single-File… I NEVER regret building the single file approach.
I am sure there are developers that work in environments where they integrate with other databases, custom in house solutions and have unique situations that may lend themselves more to a Multi-File approach. I do respect this and I would weigh their opinions as well when making your decision.
I primarily work more as a Boxed Product style of developer, meaning the solutions I build tend to be sold as products at resale or wholesale… I think you would have to hold me at "gun-point" in order to "force" me to build another multi-file solution.
Just my 2 cents worth.
Thank you Mike for your precious answer. I'll go on toward the single-file direction,
I typically like a single file solution. However, I have been working in more separation model deployment and I love it. Because I sketch out my data structure needs pretty thoroughly, I rarely need to make structure changes. So I only need to update the interface files and redeploy those. I like to have a couple different interface files. One for FileMaker Pro, one for FileMaker Go, one for IWP.
No, at the moment I use my db in local, but I don't like to be obliged to sync via iTunes all my datas, from Desktop to iPad in the morning, and viceversa in late afternoon. So I was thinking to build something much more efficient to be used on a single remote dbase (server hosted) both with iPad and iMac. That is my main reason to change the today construction seeking for smarter solution...
Does that mean that datas are in separate file/files, and that you work on empty interface-file, depending on what device you're working on?
Yes. There may be some tables, calcs etc in the Interface file. But essentially yes. The interface file would be connected to the data file, and would view the data straight from there. Scripts, etc would be in the interface file.
There are a few minor differences when you are developing in the data separation model. But it's just more getting used to doing stuff. But it is really easy. Not really all that different from a single file.
If it is only you using the file on a local network, host it from your desktop, if you have a solid network connection on the iPad this would be a quick way to go without the hassle of syncing or the cost of server.
Digital Carpentry LLC
"Let us build a foundation for your business."