More information is needed. When you say "export" what exactly are you doing?
Exporting payroll information... And it will be done in 30-something locations on monthly basis, and the problem lies in fact that the payroll data contain information and formulas that can but should not be tempered with, so I am looking for a solution in creating the safe option to transfer exported data via email.
So my first idea was to create a password protected fmp12 file which turned out to be impossible, then it was to use some other file type, but most of them can be edited with Notepad, except for maybe dbf (which is also not secure)... So there is my problem! Any ideas?
Why is using an fmp12 file for this impossible?
To be honest, because I don't know how to do it! Help, please? :)
To correct myself, I know how to export data using ffmp12 file, but I'm having a problem with doing it with a password protected one!
Hello again guys!
Does anybody know the way of exporting any kind of password protected file? I am desperate for a solution! I have tried everything...
The other option that comes to mind is to create the export file, and then delete its extension. After that I could maybe on import rename the file again with a proper extension, but alas, I have problems doing that also...
Please help guys!
Create an empty database file with the tables, fields, etc. that you need for export purposes. Use manage security to add password protection to it. Create a script in it that does an import records to import records from your main file. Insert a clone of this file into a fileMaker container field.
Whenever you need to export your data have your script:
a) use export field contents to create a new copy of the file.
b) find the records in your main file that you want to export.
c) use perform script in your main file to perform the import script in your export file to import the records into the file.
d) send the file as an email attachment.
e) move, rename or delete the copy of your export file thus produced so that you can repeat these steps. (requires a system script to do this.)
Many of these script steps will work with a variable that stores a file path. You may find this link on file paths helpful: Exploring the use of a $Path Variable in Scripts
I don't know what to say! You are the best, thank You vary much! Cheers!
This is a very broad outline of a basic idea that I have not tested. There will be quite a few implementation challenges. As I think a bit more about this, I think step e can be eliminated if you set this up so that the file is exported to temporary items, but I'd have to test that to see if it would work without needing to move, rename or delete the file.
There will be some problems with implementation, BUT, the main point is that it can work, and I can work out all the small issues that will be connected to it... There is no need for deleting it, being that the final exported file will be exported to desktop, and it will have to be emailed manually by an operator...
As for rest of the idea, I have all ready tested all of them separately, and they all work like a charm! I just need to carefully work-out steps, and that's it...
You my friend, have helped on so many issues and problems I have, that I don't know how to thank You any more...
Would this idea work with run time solutions?
The reason for deleting or moving the file is so the perform script from the main file that performs the import records script in the correct copy of the export file. The external datasource reference used by the perform script step to find the file is a "hardwired" reference so you have to place the export clone in the same location with the same file name each time in order for that to work.
There are limitaions on what runtime can do, but I can't think of any insurmountable road blocks to doing this with a run time at this time.
Hmm, and I'm just recalling that you don't have to use the perform script step if you define the correct relationship and set up a layout based on a table occurrence of the external target table in your main file, but the issue of having that "hardwired" external data source reference will still require that you export a copy of your file from the container to exactly the same location and with exactly the same file each time.
I am sorry to say that I have lost You a bit in that last paragraph! If You can give me an example of what I need to do in order to avoid the "Perform script" step, being that I have tested it, and the runtime solution refuses to perform the script in the other file, it will either say that the "import" file is not the part of the solution, or if You include it, it will just ignore the script within...
Hmm that might be a major sticking point for runtimes. The other option likely would have the same issue with the file.
You can to bind both files as part of the same solution, then insert the bound export file into the container field in the main file, but it would then take some testing to see if files copied from this one via export field contents also remain "bound" to the solution's executable file.