Transition from access to .net (visual studio)

[NigelShaw]

Hi

Here's a question. I've worked with Access now for a good while and I feel I'm quite knowledgable with vba. I'm working on a new program and wondered if it would be better in .net. I've looked over the application and the coding does look familiar and with them both being vb, shouldn't be hard to grasp.

Has anyone made the transition and was it an arduous task or did it feel mote straight forward than you anticipated? What I don't want to is start something that will need to be started again.

Comments welcome


Nigel

 

[MSAccessRookie]

Funny that you should ask that question at this time. I am currently in the middle of a conversion project. Here are some of the things that I have encountered so far:

• SQL Queries seem to fall into two categories:
  • Queries that run without user Input, which usually will convert with only a little effort.
    • Most do not support IIf() and DistinctRow
    • Most convert data types differently
    • Some do not support "Order By" equally
    • There are probably others differences as well
  • Queries that require user Input which require SQL specific handling of parameters and other user inputs.
• VBA and VB.Net are very similar
  • The vast majority of VBA code that is not Access Specific translates to VB.Net very well.
  • When code is Access Specific, conversion is usually straightforward, and in some cases, code that has been developed by other VB.Net programmers is available for you to use.
• Access Forms and Reports, on the other hand, appear to be a different story. I have yet to encounter any good tools that support the conversion process, and converting by hand seems to be a long and drawn out process.

This has been my experience to date, and I would invite anyone to jump in and provide other insights as to what to do with the Forms and Reports.

Note: For the purposes of this discussion, our database was comprised of over 100 Forms, 300 reports, and 150 Stand-Alone Queries, as well as numerous additional Queries that were built into the Forms.

 

[DCrake]

I feel that I am fully conversant with Access VBA and Visual Basic 6.0 and also feel the need to take on board VB.Net to add to my array of programming knowledge. I have Microsoft Visual InterDev 6.0 Which I assume is similar to .Net.

Is there any good tutorials about that I could use to assist in the transition from VB6 to learning .Net?

However if Visual Interdev is not .Net what software do I need?

 

[MSAccessRookie]

I feel that I am fully conversant with Access VBA and Visual Basic 6.0 and also feel the need to take on board VB.Net to add to my array of programming knowledge. I have Microsoft Visual InterDev 6.0 Which I assume is similar to .Net.

Is there any good tutorials about that I could use to assist in the transition from VB6 to learning .Net?

However if Visual Interdev is not .Net what software do I need?

David,

I was unable to locate any online resources that were of any significant value, and wound up taking a class on Intro to ASP.Net and VB.Net at my local community college. It turned out to be one of the best $100.00 investments that I have made in quite a while. There are additional classes available, and I expect to take some of them in the near future.

 

[gemma-the-husky]

I just wonder about the practicality of moving from access to VB (or any other language tbh) Access is such a friendly environment - and comes with nice db management tools.

It seems retrograde to me to consider migrating any substantial app away from access.

 

[MSAccessRookie]

I just wonder about the practicality of moving from access to VB (or any other language tbh) Access is such a friendly environment - and comes with nice db management tools.

It seems retrograde to me to consider migrating any substantial app away from access.

Here are three possible reasons for your consideration (although I am sure that there probably are more).

1. Many management people have been convinced that upgrading technology on a regular basis is a good thing, and in general, Web Applications are considerd an upgrade to desktop applications.
2. As good as Access is, it still has its limitations as to the number of users, and as to the effectiveness for users that are not located inside the Access Local Area Network.
3. Sometimes companies want to allow outside users to use their application with limited capabilities. Access cannot do this in the way that a Web Application can.

I cannot speak for anyone else, but in the case of my project, a little of each of these issues applies.

 

[DCrake]

I actually prefer VB to Access even though I have more years experience in Access.

It's just that so many contracts require VB.Net technology

The transition to web based developemnt is also one route I want to take.

The Access 2007 ribbon instantly tells the user that the app was written in Access. I like my Apps to look bespoke to the customer. VB gives m more flexibility.

 

[smig]

is there any tool helping converting the forms into VB ?

 

[MSAccessRookie]

is there any tool helping converting the forms into VB ?

I am currently investigating a product called MicroTools Access Whiz. It is a program suite that has a number of Sub-Products, and the two that I am testing are:

1. A Program that is supposed to convert MS Access Reports to Crystal Reports 11.
2. A program that is supposed to convert MS Access Forms to ASP.Net and VB.Net Web Pages.

The products come complete with at Test Northwind Database that is used to demonstrate their conversion capabilities. Each Product seems to work on the test Database (although I would expect nothing less). Although the Crystal Reports conversion was excellent, there seemed to be some rules issues in the Forms conversion.

For Instance, some of the tags like <body> and <form>, are in UPPER case, which Visual Studio does not allow. Also, there are a few instances of attributes being set that are not allowed. In total, there are not too many issues like this, and once they are corrected, the converted Web Project looks and feels very much like the Original Access Project. There are a few things that are worth noting about the issues that the Forms Conversion program demonstration does not handle, because the Northwind Database has no instances of Forms to convert:

1. While a lot of our Forms have a single Sub-Form like the Northwind examples, some have multiple Sub-Forms.
2. A number of our forms use Access TAB Controls to allow for grouped option sets that range from as few as two TABs to as many as eight TABs per form.
3. All Buttons that start a Form start a new window to display the Form in. In some cases, a window has exclusive control of the Keyboard and Mouse as long as it is opened. This was done to encourage the users not to leave these windows open.
4. Double-Clicking on some data fields causes the form to react as if a button was pushed, and VB code is executed that performs functions such as opening a new form.
5. Sometimes when a new form is opened, the default values are defined by existing values located on the form that is opening it.

The test product also allows you to preview the conversion of your own Crystal Reports that are located in Access sources other than the Northwind Database. These Crystal Report conversions seem to be about 80-90% effective, with the biggest issue being how the Previewer handles Access Reports that are called using Parameters. I expect to find that the Crystal Reports output will be able to be modified to account for these issues.

The test product does not allow you to preview the conversion of your own Access Forms, and I will not have any opinions in that area until next week, when I expect that our initial testing will be completed.



We are going with this product for two reasons:

1. It appears to convert Crystal reports at a very highly effective level.
2. It appears to convert Access Forms at least to some level, which could be a big step in the direction that we want.

 

[smig]

thanks,
please keep us informed.

though WEB pages becaome very popular these days I prefer to keep at as stand alone app. where I can have complete control over the size of the forms. in most of my app I keep forms as dialog style border and no option to resize.

 

[MSAccessRookie]

thanks,
please keep us informed.

though WEB pages becaome very popular these days I prefer to keep at as stand alone app. where I can have complete control over the size of the forms. in most of my app I keep forms as dialog style border and no option to resize.

Then you might like the Forms Conversion. It does not take into account variable display sizes, and creates a fixed, but apparently very stable display Forms.

 

[ukaquanaut]

Hi Guys
I'm quite interested in this process of converting from Access to vb.NET. I App I wrote in Access some 5 years ago has evolved over time with lots if updates and few redesign phases but I'm a couple of years from retiring and I fear there will be no one to look after the Access App I nurtured into life. So I was thinking a conversion to vb.NET would be a little more main stream if anyone was drafted in after I retire.

Its strange that Microsoft don't provide a migration tool for this they are both their products or do they?

However, in the mean time maybe I could discover some basics for example my App is split to a front end app and backend dB, assuming I do this conversion in stages, would I just convert the front end app first and retain the Access dB backend, and maybe convert to SQL Server after its running in vb.NET?

Many Thanks
Jerry