Licensing

[jal]

The Jet Database Engine is free with Windows, isn't it? That is to say, if I use VB.Net to display a Jet database, the users won't need Access installed, and therefore shouldn't have to pay for it, right?

A similar example is when I use VB.Net to output data to an .XLS file. Excel doesn't need to be installed to do it. Thus I could use the .xls file as a free database.

So here's the situation. I'm not in the IT dept. And I'm the only one in my dept with Access installed. Using Design view, I created some tables. I could use VB.Net to manipulate and display those tables - in fact I could I even have VB.net recreate the tables from scratch without any need for Access Design view. If I do it this way, then, the users shouldn't have to pay for Access, right?

 

[The_Doc_Man]

I don't know if Jet is bundled with Windows.

If you are correct that it is bundled, then you are also correct that there is no legal conflict involved in using ADO/DAO access methods via VB.NET to get into that database. The key is whether there is a separate license or an umbrella license regarding the presence of Jet in Windows. And to be honest, I've never looked.

Anyone else out there looked into this?

 

[georgedwilkinson]

I have absolutely no clue. But just some things I've been thinking about.

Jet: what does that mean? Isn't Jet an engine? That would imply that Jet is code that resides on the disk/memory as needed.

If my musings on that are accurate (no guarantee of that), then how do you "get" a database for jet to operate on?

 

[Banana]

Jet is the database engine of Access. Access is just an IDE that's well-integrated with Jet.

As for Jet's status, it used to be bundled with MDAC, then obsoleted, then transferred to Access team for further development (think it's now ACE?). So, um, yeah, I'm confused.

 

[The_Doc_Man]

George, Jet is, indeed, an engine. Access used to (by default) use DAO library to get into it when you were doing things through the interface that ACCESS.EXE provided. Then for a while it was the DAO library. Then (I think) it switched back again.

The question is not whether it resides in memory or disk, but whether it got there by a particular distribution method that did or did not include a license for its use. I don't know which (did or did not). The answer to Jal's question hinges on whether a license attaches to JET separately from ACCESS.EXE, which is really just an interface tool, or whether Jet "belongs" to Windows as a whole.

Jal, you've asked a good business question and there is nothing wrong with your logic here. It's just that usually we don't get asked a business question, so we have to think about it more. Access is (mostly) logical; business (mostly) isn't logical, so we can't just reason it out for you.

 

[georgedwilkinson]

With what you've all said, I engage in additional musing:
So if Jet is the database engine (like SQL Server is a database engine), then any "databases" that Jet manages must be stored somewhere, just like databased in SQL Server are stored in one or more files.

If you use Access to store your Jet database (that physical construct managed by the Jet engine), it is automatically called an Access database. My guess is that you would need an Access license to manage an Access database file.

Is there an alternative? Is there a non-Access Jet formatted/managed Jet data file?

And I guess your local Microsoft representative could answer this question in a snap. And the answer would probably be "send us your money".

 

[Banana]

That's the another thing I'm confused about.

From what I understand, .mdb file has the data and structure (obviously, else we wouldn't be able to just copy it and pass it along). When accessing the Jet outside of Access, I believe it will also deal with .mdb file (this is hearsay gathered from others' posts).

The Jet engine resides in a DLL (I think it's JET40.DLL or something like that), which Access obviously references in dealing with .mdb. But if you had MDAC, you didn't need Access at all, and can use ODBC or OLE DB to connect with the Jet and manage the database, even one originally created in Access. But now MDAC has dropped Jet (is MDAC discontinued as well?), the game may have changed for the newer version of Jet (now ACE).

Jet is also oddball in that there is no native CLI client to Jet, AFAIK. It always has to be managed through DAO, ODBC, OLE DB, or something like that.

Um... I'm sorry but I seem to be doing a good job of making it even more confusing.

 

[georgedwilkinson]

These are things I'd like to understand.

You can do operations on an "Access" database without Access being installed. I have proven that using Oracle tools.

Jet is an engine like SQL Server and Oracle are engines.

An .mdb is a database file operated on by the Jet engine just like a database file in SQL Server or Oracle is a database file operated on by those engines.

Question is, are there other "files" that are not mdb that Jet operates on?

 

[Banana]

You can do operations on an "Access" database without Access being installed. I have proven that using Oracle tools.

This is my understanding, also. (Haven't actually done it.)

Jet is an engine like SQL Server and Oracle are engines.

To pick nit, Jet is more similar to SQLite than it is to SQL Server or Oracle; there's no daemon running, and it's more like a file server. But yes, it is a database engine in general sense.

An .mdb is a database file operated on by the Jet engine just like a database file in SQL Server or Oracle is a database file operated on by those engines.

Indeed.

Question is, are there other "files" that are not mdb that Jet operates on?

Stumped. (My guts says no, but I have nothing to back it up)

Wait. I vaguely remembering reading something about Jet being able to operate on other ISAM file such as Paradox or Visual FoxPro....

Aha, Yes...

There were three modules to Jet: One was the Native Jet ISAM Driver, a dynamic link library (DLL) that could directly manipulate Microsoft Access database files (MDB) using Indexed Sequential Access Method (ISAM). Another one of the modules contained the ISAM Drivers, DLLs that allowed access to a variety of ISAM databases, among them being Xbase, Paradox, Btrieve and FoxPro. The final module was the Data Access Objects (DAO) DLL. DAO provided a set of methods that allowed programmers to access JET databases using Visual Basic for Applications and Visual Basic programming languages.

So Jet is actually three DLLs then...

Wiki also has this statement:

Prior to Access 2007 release, Access relied on the Windows component, the Jet engine, for its data storage and query processing

... It's not cited (unless it was referring to this citation which is a bit too much for me to wade through.)

 

[georgedwilkinson]

OK, so my guess to Jal's original question is, the users won't need a Jet or Access license, but the person who creates the database file for Jet to operate on needs a license to whatever program they create the database file with.

 

[jal]

It will take me a bit to digest everything said here, but for the moment I think my instincts serve me correctly. For example, to create ACE files you simly have to download the free "Data Connectivity Components" package available here:

http://www.microsoft.com/downloads/...36-8C28-4598-9B72-EF94E038C891&displaylang=en

Once you install it you can easily create Access-2007-compatible databases without having Access installed (I tested this a while back). When you install the package, the license window appears of course, but it's fairly short. There isn't the slightest hint about royalties in the language, as I recall. There was no indication, as far as I can remember, that special permissions are needed to use and distribute the package with software that you create.

However, if anyone hear can show me documentation to the contray, I'm all ears.

 

[jal]

OK, so my guess to Jal's original question is, the users won't need a Jet or Access license, but the person who creates the database file for Jet to operate on needs a license to whatever program they create the database file with.

That's what I am inclined to believe. I have a purchased Access 2003 installation on my computer. That justifies me in using the Design View. But the users won't need any of the Access views, not even Form View, because VB.Net will create the form. In fact, they won't even be connecting to my MDB file. The VB.net code will create a separate local MDB for each user.

 

[jal]

Microsoft seems to indicate here that Jet 4.0 is free with Windows XP service pack 2.

"If you are running Windows XP SP2, you have a later version of Jet 4.0 than the version that is included with Jet 4.0 SP8."

http://support.microsoft.com/kb/829558

 

[jal]

I just wanted to add one more consideration. These days, pretty much any time you download a commercial program or DLL for trial use, it shuts down after 30 days or so, unless you purchase a registration key. Or, alternatively, the trial use is indefinite but its functionality largely disabled. For example when I needed to write a VB.Net app with Twain document-scanning functionality, I downloaded a DLL from a third party software company, it would put up annoying registration messages every time I used VB.Net code to run it.

But with using Jet, there is none of this hassle. I think this adds considerable weight to the argument that it really is free. I admit this argument isn't conclusive, but if someone here thinks I am mistaken, then please show me a Microsoft website where I can purchase a registration for using Ace or Jet. I doubt you'll find one.

 

[Banana]

jal,

The issue is that Jet appears to be free and has no registration hassle because it always was bundled with other components. You couldn't get it standalone, had to be with Access and (in past) MDAC. Probably VB, too.

The article you linked before does pretty much settle the question that Jet is indeed a component of Windows (which makes sense to me, because I know that Office uses Jet in some fashion .... Mail Merge for example, and I suspect Windows uses Jet for its internal structure).

I'd venture to gamble that if you were to run Jet on say, a Linux, Mircosoft would view this as licensing violation because we aren't supposed to use Jet as standalone application but as a part of bundle (which in this case is now the Windows XP).

(Which brings up another question.. Is the same true of Vista?)

 

[dfenton]

Yes, from Windows 2000 on, Jet is bundled with all versions of Windows, because Jet is used as the data store for Active Directory. This version of Jet is Jet 4.0, and is maintained by the Windows development team. It should remain stable as long as it is used as the data store for Active Directory. It will also be patched for security issues and any show-stopping bugs automatically, as it's used by a subcomponent of Windows itself.

The version of Jet in Access 2007 is quite distinct and while the A2K7 version of Jet is fully backward-compatible with Jet 4, Jet 4 cannot read the new ACCDB format. The A2K7 version of Jet was forked from the Windows version of Jet and is being developed independently by the Access team. This means that you can use the built-in Jet support in Windows to read/write an MDB file (i.e., Jet 4), but you can't do the same with an ACCDB (which is the ACE format, or, de facto Jet 5).

 

[boblarson]

This means that you can use the built-in Jet support in Windows to read/write an MDB file (i.e., Jet 4), but you can't do the same with an ACCDB (which is the ACE format, or, de facto Jet 5).

So that would mean (I assume) that you would need to install the Access 2007 Runtime to have the ACEDAO engine installed.

 

[dfenton]

So that would mean (I assume) that you would need to install the Access 2007 Runtime to have the ACEDAO engine installed.

Or full Access 2007.

 

[The_Doc_Man]

This makes sense. Access is the front end, which is the thing that is actually licensed when you have an Access license. And if it is AC2K7 then there is the additional version of Jet that has ACCDB capabilities that Jet 4.0 does not. But if you use DAO routines on Jet 4.0 and never actually bother with the Access front end, you are not violating anything in a licensing agreement. If Jet is running Active Directory then it MUST be part of Windows because of the intimate nature of AD to user metadata storage.