MS Drops support for Jet...

[Pat Hartman]

I think you can use Access on a WAN. Give each user a separate copy of the fe to reduce network traffic and then just link to the be. The be doesn't have to be on a mapped drive, you can use MyNetworkNeighborhood to locate it or type its UNC name in the file name in the link dialog. I think the server has to support FTP access.

You can also use access with Citrix.

 

[shadow9449]

I know that you CAN use it, but I've read many places that it's not recommended, as Jet is not really equipped for that type of thing. It's too prone to corruption (like the kind you get when the network fails) to use on a regular basis.

If you've had success over a WAN, then let me know. Maybe I'm just falling prey to Microsoft's scare tactics in their effort to make people buy SQL Server!

SHADOW

 

[bjackson]

Here is an interesting extract from an article that i have read (late Nov 2004)

MICROSOFT INVESTING HEAVILY IN ACCESS

Last week at the Access Advisor conference in Las Vegas, Microsoft announced their plans for enhancing Access over the next several versions. In his keynote, Richard McAniff, Corporate Vice President of Access, Excel and Office Programmability, revealed the future direction for Access and their renewed commitment to the roots of making databases easy, along with SharePoint integration for web connectivity. With the largest Access development team since the early days of Access, Microsoft is refocusing its efforts on making Access the no-brainer choice for Excel users who need more power. By simplifying the development of database applications, information workers will be empowered to solve more database problems on their own. Meanwhile, the developer features will allow the continued creation of professional solutions. Overall, the investment Microsoft is making, the change in focus and simpler marketing message for Office, is quite tremendous and bodes well for the future of Access.

At ######## we are extremely pleased to see this new focus. Rather than focusing on SQL Server or .NET, Microsoft is returning focus to Access' core strength

#######################################
#######################################


My two bobs worth
In the end i think ms would have a hell of a job selling the idea of not supporting Jet/access-maybe they are just testing the water.A bit like politicians,if they dont get much negative feedback,then they WILL do it,otherwise they will just say they have no idea where or from whom that nasty rumuor started

Bjackson

 

[Pat Hartman]

I don't have any statistics but I would think that WANs don't fail any more often than LANs. Using a local fe/server be minimizes the corruption potential since the be is only "open" when the fe is requesting data. I think it's worth a try to avoid the asp issue. Although if your installation is using SharePoint, that is now an option since it is supposed to connect easily with Access.

 

[dotnetfirebird]

Access replaced by Firebird SQL

I have replaced Access with Firebird SQL. It is a full-featured database that can also be embedded (the runtime is < 2 MB). See e.g. http://www.dotnetfirebird.org/blog/2005/01/firebird-and-microsoft-jet-feature.html.

 

[Pat Hartman]

Why does everyone confuse Access with Jet?

dotnetfirebird,
Firebird SQL is a replacement for Jet, not Access unless I am reading the add incorrectly. Oracle, DB2, SQL Server, MySQL, etc. are ALL replacements for Jet. I don't think that anyone would argue that Jet can and should be replaced in some cases. The POWER of Access is that replacing Jet with a more robust RDBMS is a "piece o' cake".

 

[WindSailor]

>Why does everyone confuse Access with Jet?

Because it is synonomous... and a lot of us assimilate it as a whole.

>Firebird SQL is a replacement for Jet, not Access unless I am reading the add incorrectly. Oracle, DB2, SQL Server, MySQL, etc. are >ALL replacements for Jet.

Previously I stated...

Support has asked my opinion about it and I requested that the engine for Access in 2005 be 2005 SQL Server Express, but I added that Access still needs to be a dynamite front end for other databases also.

and your response was...

>Don't confuse the engine for Access with the engine for the data.

OK... I am probably getting a little confused...
Maybe you should expand on this...

I still think the default database for Access 2005 should be 2005 SQL Server Express, this is the base line for Microsoft and it is a mainstream product, why would Microsoft ever consider something else for a database in their database introductory program besides a mainstream product?

When I first got into Access the FIRST thing I heard was that security was a problem, and there were a lot of holes to patch to make it secure. This was to my understanding geared toward the Jet structure.

Pat, you are the most dedicated person that I know of here on this forum towards Access. What do you want in the next version of Access?

There is a niche for a more of a stand alone product that is more robust and more open towards developers needs for developing database programs than Access currently has, does Microsoft have a desire to go in this direction, does Microsoft even care to cover this niche or is Microsoft just happy to have an introductory program and settle for that?

I know you have a meeting with Clive here shortly, I hope this will inspire other developers to make their comments here... and I would love to hear your remarks about the meeting.

 

[Pat Hartman]

I am dead set against the default database being a "real" RDBMS. That is too much of a burden on the non-professional user. Believe it or not, the majority of Access implementations use Jet tables. That is because Access is a "desktop" database. I believe that Jet can be enhanced to incorporate some needed features but basically, it does the job it needs to do. Jet is what made Access the premier desktop database in the market. Without
Jet, most of my small clients would switch to Alpha 5 or File Maker Pro. They are both fine "desktop" databases and if they interfaced better with Office might displace Access. They are that good. That would leave the large corporation market for Access where most of their IT people would delete all Access databases in a heartbeat if they could since they think that Access is a toy. With the current configuration, Access scales up quite nicely. You
can substitute linked ODBC tables by simply replacing the local Jet tables with links to a RDBMS. The power of this is incredible! Think about this. Is there any other application you have built using any other tool that you can do this with? If the default data store became a real RDBMS, the scale down would not be graceful and possibly not even possible.

Take the .adp for example. It's default is MSDE and you can't even always link to Jet tables from an .adp. .mdb's are the physical files managed by Jet. They hold both data and objects. Even if the data is stored in some other RDBMS, the objects still need to be stored somewhere and that somewhere is an .mdb. (.adp's are not an option in my mind. They are missing too much and limit you to ONLY SQL server.) The drawback to staying with a single container for both objects and data is that it will never be possible to compile your app into an .exe. I would like to see the tables permanently removed from the .mdb so that all Access apps require two files. The .mdo (new extension) that holds the objects and the .mdb that holds the data. With that separation it would be possible to create a compiler so that a more secure compiled application could be delivered.

In order for the default database engine to be SQL Server Express, Microsoft would need to include tools in Access to manage an SQL server database. Since I doubt that they are going to incorporate the functionality of Enterprise Manager into Access, Access won't have any integrated tools with which to build tables. Although some management tasks can be done with an .adp. That functionality still leaves much to be desired.

And finally we get to security. I rarely use Access' internal security features because they are pretty annoying. However, in an application that I needed to retain copyright to, it is a necessitity. There is no security in an .adp except at the table level because Jet isn't used and Jet is what secures Access applications.

 

[WindSailor]

Great response... and very well put. Thank you.

I will honestly bet you, that you don't loose too many arguments do you?

Can I have more of what you are eating?

 

[shadow9449]

With the current configuration, Access scales up quite nicely. You can substitute linked ODBC tables by simply replacing the local Jet tables with links to a RDBMS

We discussed doing this a few weeks ago, but I don't think I ever succeeded. Is there instructions for this for the utter dolt (meaning me) somewhere on this forum, or on MSDN, or elsewhere?

What I want to accomplish (once I figure this all out) is to somehow create an Access database, convert the tables to MySQL (which works really well on the web), then give many users at many physical locations (perhaps different cities) an identical front end that taps into the hosted MySQL tables. From what I've read, this is possible. But I'm clueless as to where to begin. IF I can get this going, then there's no reason not to have 20 people in different cities (perhaps a chain of retail stores all checking inventory online, and head office getting sales figures in real time) using Access-based databases (Access-based meaning that I started out in Access, and just migrated to MySQL)

I wouldn't mind trying to figure out how to use MSDE to make my networked databases more robust, but I don't understand enough about MSDE to actually use it. I'm reading Microsoft's courses on the topic, although they relate more to .adp, but I am hoping that I'll get enough understanding of MSDE that way.

The drawback to staying with a single container for both objects and data is that it will never be possible to compile your app into an .exe.

If you are worried about people stealing your objects, wouldn't an .mde prevent this?

I would like to see the tables permanently removed from the .mdb so that all Access apps require two files. The .mdo (new extension) that holds the objects and the .mdb that holds the data. With that separation it would be possible to create a compiler so that a more secure compiled application could be delivered.

This isn't very different than what we all do with a front end/back end application....would be nice to be able to just compile the front end.

When is your meeting with Clint Covington?

SHADOW

 

[dotnetfirebird]

Why does everyone confuse Access with Jet?

OK, sorry Of course it should be Jet, not Access. You can see that when you follow the link. I am only using Access for working with MDB files - that's the reason for this mismatch.

What I wanted to say was that not every replacement of Jet has the Jet features that are so popular (e.g. no need for a server running separately, XCOPY data deployment, single database file...).

 

[Pat Hartman]

The meeting with Clint was scheduled for Jan 12 but we had connection problems and weren't able to talk with him. We are trying again Feb 9.

The upsizing wizard only works for SQL server so unless you have a case tool such as ERWin which can take your Jet tables and create DDL with which you can create MySQL tables, you'll need to create the MySQL tables manually. Once they are made, it is a simple matter to delete the local Jet tables and link to the MySQL tables. If your forms/reports are not already based on queries with selection criteria, you will need to do that also. Otherwise you'll be sending too much data over the network.

 

[shadow9449]

We are trying again Feb 9.

Thanks for that update. I'm sure there are many people here who are waiting anxiously for results of the meeting.

you'll need to create the MySQL tables manually. Once they are made, it is a simple matter to delete the local Jet tables and link to the MySQL tables.

Then what is the MySQL ODBC driver? Where does that come in?

Here's what I'm guessing (let me know how close I am): you go to "file", "Get External Data", "Link Tables", "ODBC", then create an DATA NAME SOURCE that links to your MySQL table that's hosted on a server somehow by entering the server information into the ODBC setup panel.

Am I close?

SHADOW

 

[Pat Hartman]

I guess you would get the driver where ever you would get MySQL.

 

[shadow9449]

Pat:

My question was not where to get it from. You get it here .

My question was how to hook up your Access front end to it once you've created the back end and hosted them on your local (or not so local )friendly Apache server. I have no experience with this, and was wondering if I'm down the right path with the process.



SHADOW

 

[shadow9449]

I was hoping that once more information about the future of JET became available, this thread would continue.

Here is something I found that addresses what will happen to JET once Office 12 emerges. It explains (as Pat frequently emphasizes) that JET is not Access, and what the relationship between the 2 are as well.

Please accept my apology if this link has been posted elsewhere already.

http://blogs.msdn.com/access/

I think that there should be at least one discussion that focuses on what is known about Office 12 now that so much is becoming available.

SHADOW

 

[Pat Hartman]

Eric did an excellent job of explaining where Jet (which may end up being called ACE) is for the next version of Access.

 

[shadow9449]

Eric did an excellent job of explaining where Jet (which may end up being called ACE) is for the next version of Access.

Yes, it was helpful.

I've spent a lot of time trying to understand how Access 12 ties in with Sharepoint, InfoPath, etc.

I think that it's time to revive this thread. There's enough information out there today to make it worth discussing.

SHADOW