MS Access 2013 and EAP files

[kepNCI]

I have read several posts about trying to use MS Access 2013 to directly read an eap file, but I could not find a definitive answer.

Is this a correct statement?:
-------------
Access 2013 cannot read an eap file unless you first convert the file via Access 2007 or 2010 to an accdb file, which then renders it unreadable by EA. Therefore MS Access 2013 and EA are not compatible. i.e., they cannot both read/update the same file.
-------------

I have no problem when using MS Access 2010. I must assume that because MS Access 2013 dropped support for JET 3.5 it cannot read eap files, even if I had the jet 4.0 enabled within EA.  

I also tried to use MS Access 2010 to convert the EAP file to accdb format, but then EA cannot read it. Thus I have come to the conclusion as stated above.

[Elpis]

> I have no problem when using MS Access 2010. I must assume
> that because MS Access 2013 dropped support for JET 3.5
> it cannot read eap files, even if I had the jet 4.0 enabled within EA.

Probably you know that, but just to be sure:
Enabling the "Use JET 4.0" in EA doesnt't make old (ie. already existing) project to be automatically upgraded to 4.0 format (assuming it has 3.5 format). In such a case Project Transfer must be done to newly created 4.0 .eap repository.

[kepNCI]

Thanks Elpis

I did know that, but I am not convinced I am creating a 4.0 jet file.

I usually run with the Jet 4.0 option enabled. Thus I was thinking that all new databases that I create would be JET 4.0 format.  So I tried a little experiement...

1) I created a new EAP database, selected class as the model and the resulting eap file was 1186 Kb.

2) I then disabled the Jet 4.0 option, restarted EA and created another new eap database, again selecting class as the model. The file size was also 1186 Kb.  I thought the Jet 4.0 file size should be larger.

Also, if I open either file with Access 2010, it says it is an Access 97 file format.  

So maybe my issue is that I have not been able to create a Jet 4.0 eap file.  

[kepNCI]

I partially answer my own question (with an assist from Elpis).

I now believe the following statement is true:
---------------
MS Access 2013 can read an eap file if it is JET 4.0, but cannot read Jet 3.5 eap files.  One must convert the 3.5 eap file to a 4.0 eap file using the transfer file to file function where the target is a Jet 4.0 file.
----------------

My mistake: I was assuming that if I had the 4.0 option set and created a new eap file, that it would be a JET 4.0 file.  
NOPE. EA was still creating a 3.5 Jet file. So, Instead of creating a new file with the JET 4.0 option set, I instead downloaded the "EABase_JET4.zip" file and used the contained file "EABase_JET4.eap" as the target.   Thus ensuring the target was a Jet 4.0 eap file.  Now Access 2013 can read it.


SO...
Now my question is:
How do I make EA create Jet 4.0 formated eap files when I create a new eap database?

[qwerty]

EA takes a default repository from EA's program files called EABase.eap. Just replace it with the 4.0 version.

q.

[kepNCI]

Yuk. Doesn't that mean that I have to replace the EABase.eap file with EABase_JET4.eap file every time I install a new EA version?  

I would have thought that EA install would have both base files in the program file and then use the "enable 4.0" option to determine which one to use when creating a new eap project.

[qwerty]

Well, this is EA. Any questions?

One of the Sparxians once told that not delivering Jet4 had to do with licensing. So maybe you should also blame Mickeysoft.

q.

[kepNCI]

I entered this issue as a bug report. Here is SPARX's reply:

---------------
The purpose of the JET 4 button is to provide support for JET 4 projects. It doesn't and isn't intended to change the format of any JET files, including new projects.
---------------

RECAP SUMMARY:
FACT: In order to use MS Access 2013 to read an eap file, the file must be JET 4.0 format. MS Access 2010 and 2007 can read both 3.5 and 4.0 JET format.
Based upon SPARX comments and experimentation, I believe the following to be accurate:

Enabling the "Use JET4 option" only is functional (at least from a user's perspective) when you have already created a JET 4.0 formatted eap file.

Out of the box, EA can only create new eap projects in 3.5 JET format. To make it 4.0 format, user must open EA with the "Use JET4 option" already enabled, then open the existing 3.5 JET formatted eap project, then use database management/file to file transfer (eap to eap) to replicate the database. The replicated database will be in JET 4.0 format. NOTE: From that point on, make sure you always have the "Use JET4 option" enabled or you will no be able to open the 4.0 formatted project.

In order to have EA create 4.0 eap projects when creating a new eap file, you have to fudge the EA program file by:

- downloading the EABaseJET4.eap file from SPARX.
- overwrite the EABase.eap file in the EA program folder with the EABaseJET4.eap

When creating a new eap file, apparently EA will always start with the EABase.eap file, thus what ever format EABase.eap is, that is what the new project will be.  Beware, that if you change the EABase.eap file in the prgram file to the 4.0 format and then run EA with the "Use JET 4.0" NOT enabled (as if to create a 3.5 format), EA will throw several errors and eventually abort.  Basically EA cannot support the creation of new EAP databases in either 3.5 or 4.0  Must be one or the other depending upon the format of the EABase.eap file the program directory.

Personal comment:
I still see it as a bug or at the very least, poor design. In my opinion, EA should be able to create a new eap file in either 3.5 or 4.0 format. I would think that would be easy to code by having both base files in the program file and using the "Use 4.0 JET" option to determine which to use.
In the current design, I an not really sure what the purpose of the "Use 4.0 JET" option is. I would think EA would determine the format version of the eap file by looking at the file instead of a use-enabled option. But apparently the truth is a mixture. Regardless of the value of the "Use 4.0 Option", if the eap file is 3.5, EA is happy and continues supporting the 3.5 format. If the "Use 4.0 Option" is enabled and the file is 4.0 format, again EA is happy and continues supporting the 4.0 format. However if the "Use 4.0 Option" is NOT enabled and the file is 4.0 format, EA throws an error that it is not a recognized file format.

I will continue to be amazed at the functionality of EA and can understand bugs that do not get fixed immediately, but in this case, SPARX has disappointed me.

[Geert Bellekens]

I understand what you are getting at, but I can also understand Sparx.
Being able too open the .eap file with MS-Access has never been a supported "feature" of the product, just a side-effect of EA using the same database format.

Personally I'm not really bothered by this because I don't think MS-Access is a particularly good SQL client.
There are much better and cheaper (free) SQL clients out there that will happily connect to a Jet 3.5 file.
I'm currently using the free AnySQL Maestro to query the EA repository.

Geert

[qwerty]

Me too. It's nice for scratch work to use EAP files. But for production use I'd never use it (except maybe for the rare case where you need it in sites that are located on North Pole or the like where you have no usable network connection and are forced to use version control/EAP).

q.

[bholtzman]

Hi all:
So I want to use MS Access to open the EAP file because I can then build some additional tracking capability along with a custom front end and because I'm very comfortable with Access (due to years of sustaining legacy applications!). I've done this already by adding tables, queries, forms and reports to the EAP file. It seems to work well. I originally added rows to some of the EAP tables but that didn't seem safe. I don't perform any operations on the data in the native EAP tables except SELECT.

So are there people who have done this and do you have any tips or cautions about it? I could add another layer of defense by creating a separate Access file and linking to t_attribute and t_object. But this would add some complexity that I'm not sure I need.

I appreciate any thoughts or ideas.

Bill

[Helmut Ortmann]

Hi,
I can only agree with Geert and qwerty.

I have seen a lot of work dumped because of inconsistent / corrupt repositories (*.eap file on a net share). If you are working alone *.eap files work well, mostly.

Usually you don't care what database is beneath EA. If you want to access EA on a real DB by Access you can do so. Query no problem, change is risky regardless of what database you use.

Regards,

Helmut

[qwerty]

It's like playing with loaded guns: nothing happens if you know what you do. Any added table/column info may conflict with future EA releases. XMI im-/export (and others like consistency checks) will not respect your tables/columns. I would always fall back to what is inside. Any addition increases complexity and reduces maintainability in exponential relation.

q.

[Paolo F Cantoni]

Well, as someone who has interacted with EA repositories with MS Access for over a decade, I can suggest some tips:

• Use linked tables.  if you are using a server based repository, rename the tables to look like .eap based tables.  Implement a linked table switcher to easily switch from one target to another.  Becuase the linked tables now have the same name, you can run the same query over any arbitrary target.
• Use the switcher to develop on the development repository then switch to production when satisfied.
• Become very close friends with the Integrity Checker [Shift+F9].  DO NOT MAKER ANY CHANGES to the repository while the checker shows a problem.  Run the checker frequently as you are developing to make sure you haven't broken anything.
• Make sure any MS Access queries use the SQL 2008 syntax rather than the Access proprietary
• Get querty's eBooks so you get to understand the internal data structures of the repository
• Ask lots of questions

Hope that doesn't deter you...  As q says - if you know what you are doing, nothing bad will happen.  However, knowing what you are doing requires discipline and persistence.

Paolo

[bholtzman]

Thanks, all. As you can see I am new to the forum and didn't realize you had answered. I turned on notifications for this topic but didn't check my spam folder!

Paolo you answered my questions exactly as intended. I definitely do not know what I'm doing at this point. But the project lead now wants to move the file to a central database for multiple users. For regulatory reasons, they also want to continue to access the tables via MS Access. Paolo that sounds like exactly what you've been doing, is that right?

I have Inside EA and read it!

Bill