[JPR] Hi Jörg,
Kirk is right, the WEDD resource stands for Wedding, and it was just a resource used to open the proper data file when starting a structure file, there is nothing mysterious about it. The WEDD resource has been removed in 4D 2004, 15 years ago. It's only use was to mary a 4DB with a 4DD. And he is also right saying that one man's 'data rescue' is another man's 'data breach'. As you know, data security is now under the full spotlights. It has always been an issue for every databases. It has always been possible to open any computer file (means also the 4D data files) brute force and try to analyse what's inside. This is why 4D has introduced encryption in V17R5, which is the only way to secure data. It's possible to find the structure of any datafile with Data Analyzer, at least for me, for I wrote it. But, for safety reasons, we have put some security in it, like not distributing the source code. Still, you can open any datafile and get the header information, described in detail in the documentation. What you cannot get if you have ONLY the .4DD file, is the names of Tables and Fields, which are save in other files (.4DB, .4DC, and .Match) But I can tell you that I got many demands for help coming from developers who have lost the DB password, or only have a compiled structure, but I NEVER got any demands coming from a total absence of structure file... Just to be clear, I told during the Tour that IF you have used the encryption feature on some Tables, AND IF you have lost the Encryption Key, AND IF you have forgotten the PassPhrase, then there is nothing we can do for you, for the encryption is an actual strong encryption. In other cases, we have always been able to help recovering data. > 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. There is no mystery about changing old resources into new ways, and we cannot tell developers in detail every minor changes made in 4D since V11, for there are too many. HTH, My very best, JPR "Errare humanum est, perseverare diabolicum" (Seneca) > Message: 8 > Date: Sun, 9 Jun 2019 00:41:27 +1000 > From: Jörg Knebel <jkne...@tttdatasystems.com.au> > To: 4D Tech Mailing List Technical <4d_tech@lists.4d.com> > Subject: Re: Open a v17 data file when Structure is unknown > Message-ID: > <0206db74-5b10-49f3-a52c-5646831d9...@tttdatasystems.com.au> > Content-Type: text/plain; charset=utf-8 > > Kirk, > >> On 9 Jun 2019, at 24:01 AEST, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> >> wrote: >> >> As I recall the WEDD was a simple string supplied by the developer. I never >> looked into how, or if, 4D used that string to create anything more complex >> like a hash. > > > Well, as a matter of fact, in pre v11 versions the developer was able to > “WEDD” structure and data with 4D-Tool(s) I think as he was pleased. > The rescue of data was always possible with a generic structure. > > 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. > > At least it would be easier to tell potential clients to fuck off because > there is nothing you can do for them - it would save a lot of time to discuss > the question “How long is a piece of string”. > > Anyway, now that I know those facts I can shorten phone requests about > similar projects. > > Thanks 4D! > > > Regards > Jörg Knebel, M.Eng. - 4D Developer since 1991 > TTT Data Systems Pty Ltd > Phone: +61 (0)2 6601 7453 > www.tttdatasystems.com.au <http://www.tttdatasystems.com.au/> > > > ********************************************************************** 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 **********************************************************************
