<div>
Total Access Analyzer does a pretty good job of depicting the structure behind your application - <a href="http://www.fmsinc.com" rel="ugc">www.fmsinc.com</a><br />
<br />
Before you commit to converting to a web app, make absolutely certain that you can actually replicate the existing functionality. &nbsp;Most client/server apps cannot be reproduced as web apps due to lack of support for important features like reports (a list rendered in a web page is NOT a report), email, word/excel automation, temp tables, charts, etc. &nbsp;Not to mention that you will need to learn a new arcane language - macros. &nbsp;They don't work the way programmers work and there is no tool that can give you a good overview of what's behind a form. &nbsp;If you think you have trouble now, you're in for something really hard to work with. &nbsp;You will have little to no control over layouts and color so if you are reliant on those things, they're gone.<br />
<br />
Start by examining the list of macros. &nbsp;Then consider the possibility of a hybrid app. &nbsp;What do you actually need web access for? &nbsp;Do people really need the complete functionality when they are off site? &nbsp;Are you trying to expose an interface for clients, i.e. users who don't belong to your domain and so cannot use the LAN to get to the database? &nbsp;Don't forget the possibility of Citrix. &nbsp;That solution will require NO changes to the existing application.<br />
<br />
Having worked for years to create client/server apps, I personally hate web apps. &nbsp;I don't like their flatness, I don't like their slowness. &nbsp;I hate all the scrolling they make me do. &nbsp;I find them to be generally unfriendly. &nbsp;Except for being pretty, they are almost as limited as the CICS transactions I was creating with COBOL in the 1970's. &nbsp;I have had several applications that I created replicated as web apps (not Access web apps) and in all cases, the users were unhappy with the results.<br />
<br />
Make sure you are going into this with your eyes open.
</div>


<div>
<div class="content wysiwyg-content">
Hi Experts,<br />
<br />
I have a pretty large program in Access that I need to re-write into web-based, and I wondering is there any tool that can read the VBA code of a given form or module and create a flowchart or report?<br />
<br />
Thanks
</div>
</div>


Hi Experts,

I have a pretty large program in Access that I need to re-write into web-based, and I wondering is there any tool that can read the VBA code of a given form or module and create a flowchart or report?

Thanks

Access/VBA to Flowchart

Microsoft Access is a rapid application development (RAD) relational database tool. Access can be used for both desktop and web-based applications, and uses VBA (Visual Basic for Applications) as its coding language.

Microsoft Access

Visual Basic is Microsoft’s event-driven programming language and integrated development environment (IDE) for its Component Object Model (COM) programming model. It is relatively easy to learn and use because of its graphical development features and BASIC heritage. It has been replaced with VB.NET, and is very similar to VBA (Visual Basic for Applications), the programming language for the Microsoft Office product line.

Visual Basic Classic

Programming theory deals with the design, implementation, analysis, characterization, and classification of programming languages and their individual features, along with introductory programming concepts like program structure, variable declaration and conditional and looping constructs. Sub-disciplines include the formal semantics of programming languages, type theory, program analysis and transformation, comparative programming language analysis, metaprogramming, domain-specific languages, compiler construction and run-time systems.

Programming Theory

COBOL (Common Business-Oriented Language) is a programming language with English-like syntax. It is readable but verbose compared to other programming languages. CODASYL (Conference on Data Systems Languages) created COBOL in 1959 based on design work from Grace Hopper. It was standardized in 1968. COBOL is still present in large-scale batch processing and transaction processing where legacy applications are being used, usually in government, financial, and administrative systems.