I'm the new maintainer of an application that was previously done by a contractor. The application was developed using VBA inside an Access project. It consists completely of forms (one of which is opened using autoexec macro) and stuff like click handlers. I don't see any use it makes of Access functionality except for accessing the tables using ODBC table linking done in Access.
These are the reasons I would like to convert this application to a standalone application if possible:
There is no version control at all, just multiple copies of the same project with an incrementing number appended to the filename
The VBA IDE is super annoying
I think the code could then be migrated to more modern languages like C# or VB.net making it more maintainable
Is there any way to convert this to a separate Windows application (I guess using WinForms as that seems to be the same as the forms in VBA) that can be maintained in Visual Studio?
Access for 20 years has supported the standard ‘Microsoft source code control interface. This is outlined in this post:
Version control for VBA file
And this one here:
How to implement version control in Access 2003?
There really little or no reason why Access + VBA, or vb.net can’t be used with source code control. However the SCC add-in that was part of Access was depreciated in 2013. So for versions after 2010, then you can use a script to export the objects. This works quite well – I am using GitHub with Access. So you need a script to export objects now that the SCC add-in is not included in versions beyond 2010 and it works rather well. Access can view each object as "logical" separate. So having all parts in a folder, a zip file, or the Access continuer is moot - don't fall for the physical vs logical concept here that so many people fail to grasp.
•The VBA IDE is super annoying
Hum, never really had much issue with it. I spend good parts of my day using VS2013 and vb.net, but for the most part the VBA IDE is fine for most Access applications. Can you give an example of what feature or something that you find bad with the VBA IDE?
•I think the code could then be migrated to more modern languages like C# or VB.net making it more maintainable
I can’t see why code written in c++, or Pascal or VBA is going to be more or less maintainable? You have to give an example of what you mean here? Maintainable code is maintainable if it is COBOL, Pascal, or VBA.
I guess using WinForms as that seems to be the same as the forms in VBA
No, Access does not use winforms.
Access as a developer tool not really different then say using FoxPro, or say Delphi. Such code and systems can be re-written like any other software development system would require that I am aware of say in the last 30 years of desktop development.
As a general rule, something written in say Delphi, or Access + VBA is not going to by some act of magic is going to be converted to WinForms and .net. That goes for just about any IDE and system I am aware of.
So software in the general computer industry never worked this way in the past, and thus Access is really much the same as most everything else in this regards.
Related
We have developed a standalone application using visual basic 6.
Now we are changing the standalone application to web application.
Is there any way to convert VB6 forms into plain HTML forms so that my work will be reduced alot.
please give your suggestions.
Edit: I am new to VB6 and .net technology
Don't even think about "converting". It's not just a "conversion" process. The entire paradigm is different between web applications and desktop applications. They're just totally different.
ASP.NET web forms try to make the differences less apparent. However, the differences are still there, and are still huge.
What you should do is separate your business logic from your forms logic in your VB6 application. You will then be more easily able to convert the business logic into .NET business logic. You'll still need to create equivalent forms, but the logic will be the same.
You cannot simply convert VB6 form to html, there is some website which provides this conversion.. but this will increase your work more
refer - VB to HTML convertor
Once I saw a DB made in MS Access that worked as a normal program, i.e with an executable file that opened a beautiful UI and allowed access to the forms and reports. I've trying to do the same, I even googled but didn't find how do it. Anyone knows how to build such standalone App with Access?
You cant make an access database into an executable file. It just cant happen however you can fool people into thinking that they are not using access a number of ways, for example
Custom splash screen (just put a bmp
file in the folder and name it the
same as your database)
Hide the access window and toolbars
Change the access icon
For example take a look at this screen shot
There are lots of things going on here and it would be hard to tell that it is built using good old access 97 (Yes I know the standard toolbar kind of gives it away, it will be going at somepoint).
I believe the tool is called the Microsoft Access Runtime toolkit or something along those lines. The latest version is free, a departure from the previous versions which I believe you had to pay for. From the previous version I tinkered with, it comes with a tool to make a EXE file from the MDB or ACCB file, a handful of icons for the EXE to use if you are lacking one, and a program to help you generate Microsoft Help files for your application.
This is a link to the Developer Extensions - I believe the 2007 version of what I described above:
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=D96A8358-ECE4-4BEE-A844-F81856DCEB67&displaylang=en
Here is a link for the runtime, which doesn't convert your Access database into an executable file, but would allow it to run on computers without Access installed:
http://www.microsoft.com/downloads/en/details.aspx?familyid=D9AE78D9-9DC6-4B38-9FA6-2C745A175AED&displaylang=en
NOTE: Both of these are for Access 2007, the version I run. Your version might require something different - but should be easily located on Microsoft's website.
If you want to fool the user in thinking that they are not using access it will take some ingenuity. I have done this. You will need a way to make nice 2D images that you will import into access, and then set them up like buttons, and give them functionality. Make sure you over lay them on a splash screen of some kind. Not sure if you know VBA but it will be needed.
At the end make sure you go in to the setting, and turn off anything that might allow the user to alter the form in any way. And then rename the file's extension like this: fileName.accdr
This is as close to a normal program that you are going to get, and remember it will only look as good as the art you put into it.
I was wondering what the advantages/disadvantages of using Microsoft Access would be compared to just creating a custom C# application. Is the execution time the same? Has its time already passed?
C# is a generic development environment designed for producing all applications that can be conceived of.
Access is a development tool specifically designed for one purpose, i.e., creating front ends to databases.
All the components within Access are prebuilt to make interaction with data as easy as possible.
While it is certainly the case that there are libraries and controls available for C# that are designed for the purpose of interacting with databases, there's less integration of the overall development environment for the particular purpose of creating database applications.
Access's database-related components are also more mature than anything that could be developed for C#, since Access has been around twice as long. That also has its disadvantage, as some of the assumptions about how things should work in Access don't work as well in a modern environment (Access was created before the web existed anywhere outside of academia).
I think it's probably OK to choose C# as a development platform for a database application if:
the developers available are already C# whizzes familiar with building database interfaces, AND
you have the need to distribute your app to very large numbers of users.
Access is somewhat difficult to deploy, and in large organizations, when you amortize the savings in RAD over large numbers of desktops, that is quickly dwarfed by the expenses associated with Access deployment issues compared to a self-contained executable with no runtime dependencies.
But we're talking about somewhere well above 100 desktops where the line is crossed (and possibly closer to 500 or 1000), in my opinion.
Access has many plus points if you are dealing with data. One key point to make is to split in your head “Access” (RAD development studio where you make forms reports code etc) and “Jet” the database engine that in bundled with Access.
Access makes a great front end of other database types such as SQL server and you can very quickly make excellent data driven applications very quickly.
You also have an excellent built in reporting suite and easy access to other MS Office applications (sending mail through outlook for example)
Access has picked up somewhat of a bad reputation in IT circles as IT departments have been burnt before by having to support some badly put together application where the original “developer” has long since left. The point is that any language can be used to make a bad application but because more people have access to err access it increases the chances of someone who is not a developer making mistakes!
In my not so humble opinion, the big advantages of MS Access are the low learning curve and the the so much is already done for you. Simple apps can be built by an untrained clerical worker.
That's also one of the biggest disadvantages. MS Access applications are often first started by complete novices and they can get them selves into a lot of trouble. Quite often they get to the point that they are dependant on the app that has been built to do their job, but it needs to be expanded, or has become unmanageable because of some early "decisions" they made they they first started building it (e.g., using some human readable key to reference another table, with no integrity constraints, etc.; and now they have a lot more data than they started with).
Typically by the time that I see it, there's a lot of work to do to undo the previous "developer's" work. And sometimes it'll cost more in time to fix it, than to start over.
Left in the hands of a pro - it's fine for building quick simple apps. Even more complex ones are OK if a pro is doing it. If I had my way, we'd just hand out the runtime version and keep the full version to the IT Pros.
The advantages are the pre-built functionality along with the ability to write custom code when needed. Of course, all of this can be done in C#, it's just not as easy.
The biggest disadvantage to using Access is having at least one answer to every question on SO suggesting using something else. Or better yet, having someone knock Access eventhough they know nothing about it or haven't used it since 2.0.
I have a huge MS Access document with built-in VBA codebase. Is it possible to track the file (as I am developing it) with a (mercurial) version control system? Can I extract code and track that? Or is it just the-binary-file-path? Thanks.
It's possible with MS Access to export most of the code through scripts. I posted some here a while ago:
How do you use version control with Access development?
It's possible to version-control binary files, but it would be a little cleaner (IMO) to have the code separate. If it works for you though, then by all means do what you do.
There is a nice tool here https://github.com/hilkoc/vbaDeveloper .
It allows you to easily export and import all your vba code and can do this automatically as soon as you click 'save'.
The export files are all plain text which you can then put in version control in the usual way.
Access all the way up to 2010 has supported source code control, and that includes support for team foundation server. The fact that you place all files in ONE zip file, one folder on a hard drive, or one container called an accDB is a MOOT point. As long as EACH individual object can be viewed as a SEPARATE object, then why do you care if one is using a zip file, or an accDB file? This is a “logical” view vs a physical view issue.
The simple matter is EACH OBJECT IN ACCESS CAN BE EXPORTED AS A TEXT OBJECT. Thus Access has supported source control integrate using this ability with the standard Microsoft SCC interface since Access 97 (that is 17+ years!!).
When you use SCC such as Visual Source safe or Team Foundation server then the BUILT IN UI in Access supports display the objects status in question. You have resolution down to the form, report, sql query and code module level. So multiple developers can all work on the application at the same time. They only need check out the forms, reports quires etc. they are working on. Each developer thus has their own local build.
If using Visual Source Safe, then you see this in the ribbon:
If you using team foundation server, then you see this:
And for objects checked out, you see this:
And when you open, or even right click on an object, you see these additional options:
Of course given that “few” use this feature or even know what it is (and the posts on SO confirm this lack of knowledge), then it is LITTLE surprise that the feature was dropped in Access 2013 after all these years!. However some 3rd party add-ins claim to restore this ability. So the ability to export objects in 2013 as individual text files STILL remains in place.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Version control for VBA file
Does any kind of version control exist?
If no, is there any good solution for collective development of MS Access 2007 database with VBA ?
Microsoft have produced a Source Code Control add-in for Access 2010:
Source Code Control add-in allows
integration with Microsoft Visual
SourceSafe or other source code
control systems to allow
check-in/check-out of queries, forms,
reports, macros, modules, and data.
You can also see the differences that
have been made to your checked out
objects.
The only one integrated VC solution for Access is Microsoft Visual Source Safe however it's poor designed and even Microsoft internally avoid from using it ;). Some people call it "Source Destruction System", but I personally know success cases with using it. Generally, it could be a good solution for small and medium projects due to its limitations.
Here is a very critical article about VSS:
http://www.highprogrammer.com/alan/windev/sourcesafe.html
The other option is to design your own code to export VBA solution using Application.SaveAsText() - it's partially undocumented feature of Access API.
I work with an Access application and Team Foundation Server Source Control. You need to switch the source control provider Access expects; I used this tool, Sourcecode Control Switcher, to do so when we moved from VSS to TFS. Once you've switched, you can setup the source control settings in Access and build a source-control-connected .mdb from TFS. It works nicely.