Hi, I'm planning at some stage to reimplement external storage but when I do I'm going to do it my way rather than the automatic way.
Reasons? 1. I got burnt once 2. If I know where the files are stored I can use them for something else (e.g. #1 point Apache or the 4D web server at them, e.g. #2 store them where Dropbox has access 3. Ability to use Time Machine for backups and not 4D Backup (not that I have anything against 4D backup but those pictures/pdfs don't need to be included overtime). Regards, Wayne Wayne Stewart about.me/waynestewart On 16 November 2016 at 10:31, David Adams <[email protected]> wrote: > I haven't followed all of the details in this thread, so apologies if I'm > off the mark. (Not that following threads keeps me from wandering out into > left field anyway.) First off, I'm glad that DvR was able to restore from a > VM. > > I had a 4D V13 database that was going to store *lots* of scanned > documents. I didn't want to keep them in the data file directly as it would > become kind of pointlessly massive. I looked at the options, tried things > out...and came away a bit worried about the outside-of-data-file story. > Here's what we did, and it seems to be working fine: > > * Store the BLOBs (PDFs) outside of the data file using 4D's automatic > feature. > > * Use a custom method to periodically (nightly, in our case) scan through > the documents and export them by hand to a different location. > > So, as a backup to the 4D system, we've got an independent export of all of > the documents organized in a hierarchical file system. Could we recover > from a disaster this way? Yeah, but it would take some work. The folder > names are based on the parent record IDs. Documents belong to something - > the folder identifies 'something'. So, with a bunch of folder-doc walking, > we could re-import all of the raw documents, but that doesn't get you any > associated data about the document, if you have any. (You could write that > out to a file next to the document, for what it's worth.) > > I know that all sounds kind of over the top, but it delivers these benefits: > > * A bit of peace of mind regarding a feature that, at the time, was new and > not well field tested. (And, in retrospect, it sounds like our concerns > weren't entirely unfounded.) > > * A snapshot backup that could itself be backed up with standard OS-level > backup tools. > > * A hierarchical folder structure that can be drag-and-dropped onto a > remote volume or served directly as a set of Web files. > > That last one actually was important for us. The same system is used in a > few databases. In one, the documents are associated with people and need to > be reviewed by various people. Once they get past an existing SSO, they can > review the people. It's not that hard to spit out a page for each person. > Since we've got a /personID/123.pdf sort of naming system, the Web page can > reference the documents using src="123.pdf", which is so, so easy to deal > with. > > Anyway, that's all kind of specific and has very little to do with the > original problem (glad it was solved already!), but it worked out pretty > well in this situation for not much work at all. > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
