OK, I'm going to throw the pigeons to the cat here - you need to define your required outcomes first. and the main question is... who are the users? Does this really need to be a web enabled application? If your users are all known, internal users, then why does it need to be web enabled? It probably doesn't. And I'm guessing that as a VB6 app this will be the case. If all the users are internal and you can dish the application out as a desktop application, even via Remote Desktop Services then your most cost effective solution may be an Access application (hears howls from the gallery). But it will do the job at a fraction of the cost of a .net application. If it need to be web enabled, or it really needs to be .Net then don't fluff around with VB.net, just learn C#. It's not that hard. But it will be time consuming and hard on the budget because it's .net, not because it's C#. There is a reason why VB6 has been hard to kill and it little to do with syntax.

Kent

Hands up anyone who skipped vista and went straight from NT/2000 to 7. Hands up anyone who skipped 8 and waited for 10 Hands up anyone who doesn't see a pattern

Well that depends on how you are remote accessing. For example, With MS's RDS your displays are driven by the remote machine. With Google's your resolution and number of monitors is driven by the host machine. Horses for courses.

There was a bloke lurking out the front of my house yesterday. He was sticking bits of paper into slots in a box that I'd never noticed before. I asked him what he was doing and he explained that there is this thing where you can write a message on a piece of paper and give it to someone who gives it to someone and then they give it to someone ... and eventually someone sticks it in the box outside the house of the person you wrote the message to. And they get it. But most intriguing of all is that when they get it, and they read it, they are highly unlikely to contract ebola!

I agree with you on the SQL issue and this is a very good case for moving the BE to SQL Server. Developing complex queries in SQL Server is just so much easier. CTEs rock! I'm currently building a very complex report using Access without SQL Server and it really does suck trying to do this in the Access Query Builder. But that doesn't mean you should trash Access for building the UI.

MS may have just wasted 6 year of development on Access Web apps which they have now discontinued they are now full steam ahead on developing Access Desktop. Now that Azure allows you to host an Access desktop app in the Cloud there was simply no need for a dedicated Sharepoint hosted version of Access and about the only time Access will not cut the mustard is if you need to cater for anonymous users like on your typical public access web site.

Good point about Express and also note that the developer version is now free. The combination of Access and SQL Server is quite powerful and RAD. I'll often prototype a process using VBA recordset (easy to debug but slow to run) then convert the process to use T-SQL. Although I usually use Pass Through queries (PTs use ODBC) to execute SPs, it's nice to know MS have reversed their decision to deprecate ADODB (and therefore ADO). Once you replace your BE with SQL Server then there really isn't much to hate. Even if I do need to use .Net you can always build a COM enabled DLL to consume in VBA. My observation is that some developers, including myself, would love to have a client pay for their time to learn or improve just employ their C# skills. Unfortunately there is rarely a business advantage for the client. Apologies to Gerry for hijacking his thread.

No sorry Gerry, I was commenting on the original post.

So why not move the BE to SQL Server? There may certainly be a business case for that. Stability and speed. In those respects Access, as a database container, is certainly inferior to SQL Server. And then there is the ease of creating SPs using CTEs etc that is way better than the Access Query Builder. But as a tool to build user interfaces, ie forms and reports, for a custom solution it is very cost effective and in the hands of a good developer there are few restrictions. So what is your business case for rewriting their entire application?

Good that you have started to write and post. It's a great way to learn as you get feedback, whether it's phrased in a kindly manner or not, there are often little gems that you had not have thought of. I often find that I get half way through a post and realise that I'm totally wrong and discard it. But simply writing the post allowed me to clarify my idea to myself and see why it was wrong.

The important thing to remember is that people learn in small steps that each build on the last, so getting the order right and keeping each step small is important. The reader needs to be able to say "I got that" before moving on to the next lesson. When writing I use Word's headings. I start with Heading 1 style and then gradually drill down to greater detail using Heading 2, 3, 4 etc then get to the fine detail Then when I review my logical sequence and see that, well you need to know this before you can comprehend that, I may rearrange the order using Word's outline view that allows me to collapse a section to say Heading 1 and easily move the entire section. Once I've said all I need to say then I take the list of Headings and distil them to create the overview and summary. The overview items fall into perspective if you start each one with "By the end of this article you will be able to..." With experience you can get more creative but to start use that "by the end of ..." The summary is the same but with different wording where you briefly recap each section to remind the reader of what they just learned and maybe crystallise it in their minds. Like this - So to recap - Tell them what you are going to tell them in the overview give them the detail keep your sentences bite size Build each new section on the knowledge gained from the previous and then tell them what you told them in the summary

Simple rule for training or instruction is - Tell them what you are going to tell them Tell them Tell them what you told them in other words - give an overview in simple point form here you should start with a paragraph that allows the reader to decide whether the content is relevant to them. After reading that paragraph they should be able to decide whether to read on or not. deliver the details Keep the paragraphs short. No more than a few sentences. This allows the reader to take bite size information. Nothing turns me off more than long paragraphs that I need to reread 3 times to get it. then recap with simple reminder, in point form, of what you told them. When I write I start with a list of things I want to talk about, rearrange the list so it gradually builds on the previous knowledge. This reinforces the previous while providing small steps. it's also good to use examples that the target audience can relate to. In this case it's developers so an example that uses Dilbert and his pointy headed boss would be appropriate. Hope this helps.