Solved Recover accdb from accde

[Pat Hartman]

Lucky for me, I wasn't that concerned about keeping the code private. My clients are very large companies. If they decide to recreate the app, they would do it with a web tool because that is what is "in". They would not risk stealing code they can't actually use. They would be using the BE as is (unless they decided to flatten it and make it un normalized) and the forms and reports would be a template for the replacement versions and I can't copyright that or do a thing about it. The key is to keep the annual price low enough so they are not tempted. They would need to spend at least a million dollars to recreate it as a web app. The regenerated code is indented correctly although my code started out that way but it has space lines in illogical places so it looks more like code written by a C# programmer. Also, I'm comparing it to code that is slightly different. It feels strangely sterile without any of those green comment lines interspersed

I've had two clients reimagine apps I built for them as web apps. In one case they spent over 3 million dollars and it took a team of 4 over two years to complete. I only know that because I remained friendly with one of my users after I finished the app and moved on because she was a bridge player. The original app took me, working alone, about 6 months of effort over the course of a year. I did other projects for the same client and we improved the original version of the app over time. I think that one of the problems was that they partially recreated Word as part of the project so the users could edit the documents and bookmark them using a web page rather than Word. I think they didn't know that they could resave all the existing Word documents as .rtf which is a plain text format rather than a proprietary format. That would have allowed them to continue using Word but give them plain text files to populate.

 

[gemma-the-husky]

Lucky for me, I wasn't that concerned about keeping the code private. My clients are very large companies. If they decide to recreate the app, they would do it with a web tool because that is what is "in". They would not risk stealing code they can't actually use. They would be using the BE as is (unless they decided to flatten it and make it un normalized) and the forms and reports would be a template for the replacement versions and I can't copyright that or do a thing about it. The key is to keep the annual price low enough so they are not tempted. They would need to spend at least a million dollars to recreate it as a web app. The regenerated code is indented correctly although my code started out that way but it has space lines in illogical places so it looks more like code written by a C# programmer. Also, I'm comparing it to code that is slightly different. It feels strangely sterile without any of those green comment lines interspersed

I've had two clients reimagine apps I built for them as web apps. In one case they spent over 3 million dollars and it took a team of 4 over two years to complete. I only know that because I remained friendly with one of my users after I finished the app and moved on because she was a bridge player. The original app took me, working alone, about 6 months of effort over the course of a year. I did other projects for the same client and we improved the original version of the app over time. I think that one of the problems was that they partially recreated Word as part of the project so the users could edit the documents and bookmark them using a web page rather than Word. I think they didn't know that they could resave all the existing Word documents as .rtf which is a plain text format rather than a proprietary format. That would have allowed them to continue using Word but give them plain text files to populate.

Ite surprising how efficient a single developer can be when the developer has a very close understanding of the client's needs. Not only does it cost a lot, I expect there are areas in which they struggle to match the functionality of the original.

 

[Pat Hartman]

Everybody loved the app because it made such a positive difference in their workflow and the IT people in the UK even liked it so much they eventually copied it. This was a new US subsidiary of a UK insurance company and they were developing new products regularly. It was taking their UK IT group 4+ months to update their web app to handle each new product which makes it hard to satisfy local business needs. Hence the Access app which had an entity/attribute schema where there were tables with fixed data columns and also one that stored each piece of data in a separate row. This allowed the users to define new attributes to satisfy the needs of the new products by simply adding the name of the new column and defining it in the column definition table. A trained user could define a new product and any new columns required to support it in a couple of hours instead of the 4+ months needed to modify the properly normalized web app. It would still take days to create the necessary Word documents depending on how many they needed and how different they were from existing documents.

The Access app could use the schema it used because its entire purpose was filling out forms. The biggest issue with a business process like this is ensuring that there is no conflict in any data in any of the documents. The actual schema was inefficient for long term uses like reporting so it kept only three versions of a policy. The current version and the previous two renewals. Then the data was archived. The old mainframe system still needed to capture whatever data was needed for historical reporting.

 

[BenKuperstein]

My project might be useful in cases like this, check out AccessAccdeDisassembler on github

 

[isladogs]

@BenKuperstein
See my reply to your other thread: Access Accde files Disassembler | Access World Forums (access-programmers.co.uk)

 

[The_Doc_Man]

This was a special case because Pat was working on an older version of her own product. However, as a matter of formality, everyone involved should realize that it would be possible to reverse-engineer things that might be legally protected against you. There is a risk having to do with reverse engineering anything. Therefore, if you offer to do this for "a friend" - or if you have an MDE or ACCDE file to be decompiled - just be aware of the end user license agreement that applies to that particular product.

Again, this thread started with Pat working on her own product so the EULA did not apply. But folks reading this and thinking it is a great way to look at someone else's code, please think again. Moderators and VIPs, please remember that we have a duty to Jon to not involve the site in any scheme that potentially involves reverse-engineering of someone else's code.

 

[gemma-the-husky]

It is. The old conversions used to be pretty terrible, usable only in a pinch because the variable names were meaningless. The newer ones actually recover the variable names also so the code reads pretty much as it was written.

Thanks Joseph.

I know this is an old thread, Pat, but Wayne has a product that strips out the variable names to prevent such powerful disassembly. All variables are just recovered as var1, var2 etc, which would make code rather harder to follow.

Edit. I already mentioned this about a year ago, I see.

 

[Pat Hartman]

I know this is an old thread, Pat, but Wayne has a product that strips out the variable names to prevent such powerful disassembly.

I know but that wasn't what I needed. This was a version of the app from 2009 and I couldn't find the precise build that the client had so I needed to have THAT file disassembled into a useable format.

The product you are referencing is used to obfuscate all your variable names so before you make the accde, the variables are already unreadable then even if someone later manages to decompile it, they get unreadable code. I have a new product that I will be selling and since I would not have any future contact with the customer, I might use that tool.

 

[gemma-the-husky]

I know but that wasn't what I needed. This was a version of the app from 2009 and I couldn't find the precise build that the client had so I needed to have THAT file disassembled into a useable format.

The product you are referencing is used to obfuscate all your variable names so before you make the accde, the variables are already unreadable then even if someone later manages to decompile it, they get unreadable code. I have a new product that I will be selling and since I would not have any future contact with the customer, I might use that tool.

No, not quite. You produce an accde normally, and then the code protector reprocesses the accde to remove the bits that identify the public variables and constants.

I use it to make decompiling my accde files difficult, but it clearly does come with the problem that you can't reconstruct the original accdb from the protected accde.