Solved Recover accdb from accde (1 Viewer)

[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.