1

I need to update (well, rewrite really) a SMALL VB6 application which uses ADO to access a JET database, to a vb.net app in Visual Studio 2008.

My research suggests that I should use LINQ, but it doesn't seem to be possible to connect to JET. If JET is now deprecated, what should I use? Or should I use ADO.NET without LINQ?

Please don't answer SQL Server! - this needs to be an app that end users can install easily in corporate or non-corporate environments, and must not require any ongoing technical maintenance. I started to install SQL Express, but stopped when it required at least 2 system updates, as that will be far too complex for this little app.

MarkJ
  • 30,070
  • 5
  • 68
  • 111
SM.
  • 79
  • 1
  • 9
  • what are you updating in it, for you to use .net? I know, one should upgrade the tools/technology. What is the business reason for it? – shahkalpesh Jul 22 '10 at 10:00
  • @shahkalpesh: I don't know of his reason, but I know that many clients worry about VB6 apps when they discover that it's no longer supported by MS (even if they never use the support, it still makes everyone feel better). – Hans Olsson Jul 22 '10 at 10:04
  • Reason is solely that I have been instructed to port all VB6 apps to .NET! – SM. Jul 22 '10 at 10:11
  • 2
    It might be worth asking the decision makers why they've decided to port to .Net. The VB6 runtime is part of all current versions of Windows and is fully supported http://msdn.microsoft.com/en-us/vbasic/ms788708.aspx. Similarly the Jet engine is part of all current versions of Windows and is fully supported. Obviously there are lots of good reasons to port to .Net, but don't dash into it because you think VB6 is no longer supported. There's less urgency to port working VB6 apps that don't need to be changed or extended. – MarkJ Jul 22 '10 at 11:38
  • **@MarkJ:** VB6 apps are supported up to Windows7, but *Visual Basic 6.0 IDE is no longer supported as of April 8, 2008* (statement in the link you provided...) This means that as a programming language, VB6 is dead. It will no longer evolve with the technology changes that is going on. – awe Jul 22 '10 at 12:03
  • 1
    Did the VB6 IDE stop working on Apr. 8, 2008? – David-W-Fenton Jul 22 '10 at 17:57
  • @awe Correct. That's why I wrote "there's less urgency to port working VB6 apps **that don't need to be changed or extended** " If you aren't changing or extending your app, the IDE doesn't matter and nor do the technology changes. – MarkJ Jul 22 '10 at 20:00
  • @MarkJ: Yes, that is a good point . **Working VB6 apps that don't need to be changed or extended** is not important to convert. – awe Jul 26 '10 at 12:24

4 Answers4

1

Jet has been deprecated but there's a replacement in the form of ACE (Access Database Engine).

However, regarding using it from LINQ. The answers to this question have various suggestions and I've also read somewhere that it might be possible to use LINQ to DataSet to do it. Here's a blog post about it: Querying DataSets – Introduction to LINQ to DataSet but I can't find the link to where I read that someone had had success in using it to access an Access DB.

I'd suggest though, that if there are no clear cut solution for using LINQ, the pragmatic approach would be to just stick to normal ADO.Net and wait with using LINQ until you're sure that you're using a datasource that supports it fully.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Hans Olsson
  • 54,199
  • 15
  • 94
  • 116
  • How close a replacement is ACE? And will there be problems installing on clients running XP? – SM. Jul 22 '10 at 12:48
  • @SM: I'm not sure I'm afraid. My understanding is that it was developed by the Office team when Jet was deprecated and is supposed to be fully backwards compatible with Jet, but that it contains some new features if used with .accdb files rather than .mdb files. Since it came out with Office 2007 I'm fairly sure it'll work fine on XP. – Hans Olsson Jul 22 '10 at 13:07
  • 2
    Jet has not been deprecated. Period. End of statement. MS has been recommending different technologies for its flagship development tools, but that's more a matter of the transition from VB to the .NET languages than it is something to do with the future of Jet/ACE. – David-W-Fenton Jul 22 '10 at 17:58
  • 2
    ACE is not a replacement for Jet -- it *is* Jet, just the next version of it with a new name. Jet 4 remains frozen as part of Windows, and the ACE will not be incorporated into Windows as Jet 4 was. – David-W-Fenton Jul 22 '10 at 18:00
  • @David: Well, according to Microsoft it's deprecated and they won't do any new development on it, including that there's no 64bit driver etc. When it comes to ACE vs Jet I won't argue since I don't know the details but even if it's more or less Jet 5, I'd still differentiate between them by using their official names, in the same way as I say "Windows 7" rather that "Windows Vista R2". – Hans Olsson Jul 22 '10 at 19:46
  • http://msdn.microsoft.com/en-us/library/ms810810.aspx http://support.microsoft.com/kb/957570 – Hans Olsson Jul 22 '10 at 19:46
  • 1
    The URL you cite is a perfect example of what I already addressed, that the transition to .NET has caused MS to recommend different db technologies. Jet may be deprecated in that context, but it's alive and well in many other contexts. You're wrong on 64-bit and on lack of development. Jet *4* is frozen, but not the Jet database engine -- it's just called ACE now. If you mean Jet 4, then say Jet 4, but you have to realize that when you do that, you're making a much less sweeping statement than you original assertion. – David-W-Fenton Jul 23 '10 at 20:17
1

Here is a good upgrade tool that is free if your project contains less than 10000 lines of code:
http://msdn.microsoft.com/en-us/vbasic/ff793478.aspx

The general approach you should follow, is first a clean migration from VB6 to VB.NET, and get the .NET version to work exactly as it did in VB6, and then start to look for alternative technologies in .NET. It is easier to convert between different technologies when you have a working .NET application than to manually try to convert directly from VB6 code to alternatives in .NET.

Here are some good reasons to migrate first instead of a manual rewrite:
5 myth busting reasons for choosing automatic migration vs manual rewrite

From the article:

even in the worst case scenario, where you still need to rewrite a certain piece of the application after the automated migration phase, the end result will always be a fraction of the total cost and time.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
awe
  • 21,938
  • 6
  • 78
  • 91
  • I don't disagree with your suggested approach, but once ported, it will never be rewritten in more 'correct' vb.net. This is really the only opportunity to rewrite the app using more up to date methods. – SM. Jul 22 '10 at 10:15
  • You will probably spend less time following this approach, just don't tell your boss that it is converted before you have done the rewrite after converting... – awe Jul 22 '10 at 10:30
  • Thanks for the link to the upgrade tool. We were not impressed with the VS automatic upgrade but I will give this one a go. – SM. Jul 22 '10 at 11:10
  • If your project is less than 10000 lines of code, it will be an excellent test of the tool. If it works good for you, you might want to consider buying a license to handle larger projects as well... – awe Jul 22 '10 at 11:17
  • +1. That tool has an excellent reputation. It's also worth considering the main competitor VB Migration Partner, which also has a very good reputation. http://www.vbmigration.com/ – MarkJ Jul 22 '10 at 11:35
  • 1
    One word of advice. Do be careful about rewriting using more up-to-date methods unless the app is really very small. It's a common pitfall to get bogged down doing the rewrite - that's when your bosses get upset with you. – MarkJ Jul 22 '10 at 11:36
  • 2
    cf: Spolsky on Netscape: http://www.joelonsoftware.com/articles/fog0000000069.html – David-W-Fenton Jul 22 '10 at 18:01
  • Ran the upgrade tool, but it wasn't overly helpful for the code I have. Everything it upgraded correctly, I could have done easily, and the rest needed to be rewritten to remove the rather strange intermediate functions it created. So, interesting, but no more useful than the inbuilt upgrade wizard. MarkJ - 5600 lines. I call that a very small app. All done bar changing the way I connect to the db in one afternoon. – SM. Jul 26 '10 at 15:04
0

These may be of interest:

Which O/RM tool supports Microsofts Access? http://blogs.msdn.com/b/adonet/archive/2007/01/26/querying-datasets-introduction-to-linq-to-dataset.aspx

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Fionnuala
  • 90,370
  • 7
  • 114
  • 152
0

Just use OleDbConnection / OleDbCommand / OleDbDataReader objects to mimic the same logic that you have in the VB6/ADO code. It will work the same way and not require any more dependencies than your existing app.

Christian Hayter
  • 30,581
  • 6
  • 72
  • 99
  • So you think I should continue to use JET? – SM. Jul 22 '10 at 11:27
  • Yes. JET won't suddenly stop working because you have re-written the client code in a different language. Whether JET actually exists on your target machine is a matter for your setup program. This is a problem you have already solved when deploying the VB6 code. – Christian Hayter Jul 22 '10 at 13:47
  • Jet 4 exists on all versions of Windows from Windows 2000 on. The 64-bit situation is murkier -- I'm not sure what 64-bit versions of Windows do for the purposes that Jet is used for (Active Directory), or if the 64-bit version of Access (2010) provides a 64-bit ACE and a 64-bit Jet. The latter seems unlikely to me, but I can't see how they can provide 64-bit Access without supporting MDB files, so they must have created a 64-bit version of Jet (so far as I can tell, A2007 and A2010 do not use the ACE to interact with MDBs, but use Jet 4; cf: DAO references, for instance). – David-W-Fenton Jul 22 '10 at 18:04