How about the ability to create a FMP file from a DDR?
VERY usefulkl, it would be the cure (or the good workaround) for file corruption
Moreover, we could create a DDR from scratch and automatically create filemaker files
It would be also a fantastic tool for pro amp dev, because they could reuse code much more easily and have kid of templates files, that they could personalize automatically
This would also produce a strong force inside FileMaker to make the DDR include all of the metadata about the database, rather than just most of it.
That would be be my concern. And what about the security stuff? do you really want that exposed in the DDR? and if it's not, how can you truly re-create the File from the DDR?
I don't see the security problem, those who have control of DDR export are admins, and hence have full power.
If you're thinking about odbc passwords, well to me I don't mind having them in DDR export. But you FM could not include those in the DDR.
Then, in the reconstructed solution, they would have to be re-entered. Re-entering those would be a very very little job compared to recreate the solution by hand. So we should not discard this huge functionality just for those
This may be another discussion or idea...but if FM segmented the passwords and security. You could technically just reinsert those segments into a new file. There exists some considerations with that also, I suppose. But done right, could work.
Some time ago FMI stopped offering the File Recovery service. I think that is because even they cannot get into a file. Now with Encryption At Rest (EAR) the file is completely inaccessible if you lose the Full Access Account information.
The log-in security in a FMP file is much more than a place or segment in the file. What you envision is simply not possible in the FMP12 file format. Any attempt to do so will result in the "This file has been tampered with" message and the file will be inoperable.
Sure. If asked for [Full Access] credentials, you could test it that way.
EAR: Yup. As I would fully expect.
I've worked with people that know where the security stuff is in the file, and can overwrite that data. Similar to how password crackers work. With that being the case, I would assume FMI at least knows how to identify the location of the security stuff in a file format. In an unencrypted file of course.
Note...that I may fully be off-base with my assumptions. Just thinking out loud.
I an sorry, I do not want to hijack this important discussion, just rectify one misunderstanding here.
Now with Encryption At Rest (EAR) the file is completely inaccessible if you lose the Full Access Account information.
Just to comment on one misunderstanding. No, EAR has nothing to do with Full Access, they are two entirely different features, not even controlled within the same part of FileMaker. And even with full access you can not get into a file if you lost the password for the EAR.
You could say that EAR is a final layer of security to use where you are afraid that unauthorised persons could gain access to the file and circumvent the security layer. With EAR we at my company regard the combined security model of FileMaker to be very very reliable. But we are only using EAR where we find it needed.
Until FileMaker 11 the now discontinued FMrobot did most of this.
Created a new FileMaker file based on the DDR.
It did not transfer the accounts but it did transfer the privilege sets. And the windows version even recreated TO's and relatioinships.
It is discontinued and can only be used up until FileMaker 10.
I have voted this feature up, but I hope/believe that it will become less relevant over time.
One reason why we only very seldom meet corruption may be that we are keeping our solution files a little bit simpler by separating the data layer from the logic/presentation layer. We store the tables in one file with very very little functionality (only minimal TO/TOG, security and calculation fields). And everything else in a set of UI files. At least if it is for larger solutions. With smallish solutions used by one-five users we tend to keep everything in one file.
Retrieving data ...