v16.1 - Project Transfer - Why is 64-bit 8x slower for the same transfer?

[Paolo F Cantoni]

We've only noticed this because we usually run this process in 32-bit versions (v15.2 and v16).  Under 32-bit versions, the Project Transfer of a large SQL Server repository to an MS-Access Snapshot file takes about 15 mins.  Under 64-bit versions, the SAME Project transfer on the SAME machine takes 2 hours!  This has been confirmed on several systems.
We are using SQL Server 2019 and have installed the latest 64-bit drivers on all the machines.
Our DBAs have suggested a reason (that has to do with the Sparx EA application and not SQL Server); however, I don't want to affect anyone's response at this time.

Does anybody have any suggestions as to what is happening and why?  Are there any solutions (other than always running this under 32-bit versions of EA)?

TIA,
Paolo
[Edit: the Project Transfer under previous 32-bit versions (i.e. before v15) also took approximately 15 mins.]

[Modesto Vega]

Hi Paolo,

Are you experiencing the same performance issue transferring to a qeax file? Are you running MS Access 64-bit or 32-bit?

[Paolo F Cantoni]

Hi Paolo,

Are you experiencing the same performance issue transferring to a qeax file? Are you running MS Access 64-bit or 32-bit?

Hi Modesto,
We're not using qeax files, only eapx at this stage.  We have 64-bit Office 365 with MS Access.

Paolo

[Takeshi K]

Hi Paolo,

I think this is not a bug or issue of EA, but because you use a different driver from 32-bit environment.

MS-JET only supports 32-bit applications, so EA cannot use the same driver but use the Access 2010 or later drivers. The Access 2010 driver 'emulates' JET driver, so I think performance must be lower compared to the 'native' driver.

So, what I want to say is that I guess it must be a problem of EA (this means Sparx cannot do anything technically). If my guess is correct, to solve this issue we need to use file formats which support 64-bit environment natively (e.g. FEAP or QEA).

[Paolo F Cantoni]

Hi Paolo,

I think this is not a bug or issue of EA, but because you use a different driver from 32-bit environment.

MS-JET only supports 32-bit applications, so EA cannot use the same driver but use the Access 2010 or later drivers. The Access 2010 driver 'emulates' JET driver, so I think performance must be lower compared to the 'native' driver.

So, what I want to say is that I guess it must be a problem of EA (this means Sparx cannot do anything technically). If my guess is correct, to solve this issue we need to use file formats which support a 64-bit environment natively (e.g. FEAP or QEA).

Hi Takeshi-san,
I have confirmed the same behaviour in SQL Server to SQL Server transfer.  It doesn't seem to be directly related to MS Access.

Paolo

[Modesto Vega]

Hi Paolo,

I will try reproducing this with a transfer to a qeax file. Transfer to these qeax should be a native 64-bit implementation, both Access and SQL Server were for a very long time 32-bit implementations, and, considering Sparx Systems quality assurance track record, it is not impossible that some 32-bit components are still lurking unnoticed in the background.

[Takeshi K]

Hi Modesto,

Using qeax might have a different reason. If you can transfer to a qea (not qeax) file in shorter time on the same environment, it is because qeax files support multiple users' access by using cache (journal) file very limitedly. Performance of QEAX is usually worse than QEA because QEA uses a journal file to be better performance.

[Modesto Vega]

Hi Takeshi,

Fully agree that a QEA file should provide native 64-bit support. The following has caught my attention:

[SNIP]
it is because qeax files support multiple users' access by using cache (journal) file very limitedly. Performance of QEAX is usually worse than QEA because QEA uses a journal file to be better performance.

I find interesting that you seem to suggest that the cache (journal) could be causing the performance issues and that chaching (journaling) may not even provide native 64-bit support.

[Geert Bellekens]

I noticed the slower project transfer now as well on EA v16.1.1622 (64 bit) when doing a project transfer using the API from SQL server to .eapx file.

I wanted to transfer to .qea file, but the API won't let me. (bug reported)

Will do a comparison with manual export to .qea as well.

Geert

[Geert Bellekens]

Testresults:

EA v15.2
- Automated Project transfer to .eap file => 6 minutes
EA v16.1.1622 (64 bit)
- Automated Project transfer to .eapx file => 35 minutes
- Manual project transfer to .qea file => 9 minutes

Geert

[Modesto Vega]

[SNIP]
- Automated Project transfer to .eapx file => 35 minutes

I am not convinced that a transfer to .eapx is fully/native 64-bit. This is also the way I read (between the lines) Takeshi's replies.

[Geert Bellekens]

[SNIP]
- Automated Project transfer to .eapx file => 35 minutes

I am not convinced that a transfer to .eapx is fully/native 64-bit. This is also the way I read (between the lines) Takeshi's replies.

Definitely true, says so in the log file:

| Target
|    Connection:        Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\temp\Output\Backups\LogFile\EA_Export.eapx;Persist Security Info=False;LazyLoad=1;DBType=8;
|    DBMS:              ACCESS2007

I guess this is one of the reasons they went to SQLite as the default file format in v16.

Geert