Jorg, Well, one man's 'data rescue' is another man's 'data breach'. Frankly it sounds a little hinky that a client would have a lone datafile and no clue about where the structure file is or who created it. But I have run bars and restaurants in my past and am suspicious of stories like that.
In general I think 4D's tightening up of data security is a good thing. Yes it creates headaches when good people do stupid things but on the whole is a better architecture by limiting opportunities for bad people to do bad things by intent. FWIW - I recall JPR admonishing us at a Summit a few years ago regarding the 'security' of the proprietary datafile. To paraphrase, "you may think your data is somehow encrypted in there. IT'S NOT!" So the file could be analyzed and data recovered. This also changes in v17r5 (I think) where we can now encrypt tables. On Sat, Jun 8, 2019 at 7:41 AM Jörg Knebel via 4D_Tech <4d_tech@lists.4d.com> wrote: > NOW, the new “WEDD” is integrated and the developer is fu****, if he has > to do some kind of data rescue. > > It doesn’t matter what algorithm and/or encryption is used by 4D to > realise that “New WEDD” function, disturbing is , that 4D did not inform > the developer community in detail about those changes. > -- Kirk Brooks San Francisco, CA ======================= What can be said, can be said clearly, and what you can’t say, you should shut up about *Wittgenstein and the Computer * ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
