Book a Demo

Author Topic: Native XML import (project transfer) non responsive  (Read 6807 times)

rmvanderlinden

  • EA Novice
  • *
  • Posts: 18
  • Karma: +0/-0
    • View Profile
Native XML import (project transfer) non responsive
« on: June 08, 2020, 01:32:24 am »
I work from home and have a VPN connection to work. I want to transfer my work repository (Postgres) to another work repository (MS SQL). When I did at work site (without VPN) it took about 6/7 hours to transfer. Now I am working at home, the project transfer fails. So I did a Native XML export from my Postgres to my local laptop. This takes about 20 minutes (1,4 Gb). When I do a Native import to my MS SQL it fails (after waiting > 9 hours). I did it about 8 times, but all fail. Reason unknown. There is not log available. Also, and maybe the biggest pain point is that when the transfer/export begins, the screen freezes and is not updated anymore. The task manager always indicates that EA is not responding. I have no clue if the transfer is busy or stopped. Most of the times EA (15.1 and also 15.2 beta) just quit without any notification. The only clue I have is the Ethernet Status which give me an indication that bytes are send/received.
So, is there a place where I can watch the progress, see the log why it stopped or failed, can unfreeze EA. Any help, hints or cases look like this are welcome.

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Native XML import (project transfer) non responsive
« Reply #1 on: June 08, 2020, 02:47:01 am »
Not much help possible. Do this: transfer an EAP to the server. Then issue a Transfer EAP right on the server with that EAP. That will basically do a table copy. A transfer to EAP is relatively fast since it's no real DB and does not have to do much with database constraints, indices and so on. Vice versa transfererring to a SQL server takes much longer then.

q.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Native XML import (project transfer) non responsive
« Reply #2 on: June 08, 2020, 04:04:33 am »
I agree with q. Best bet is to do a project transfer to .eap, and then a project transfer to MySQL.

Make sure to run a project integrity check beforehand, and possibly delete audit records and stuff to make the database as small as possible.

Geert

rmvanderlinden

  • EA Novice
  • *
  • Posts: 18
  • Karma: +0/-0
    • View Profile
Re: Native XML import (project transfer) non responsive
« Reply #3 on: June 08, 2020, 05:10:06 am »
Eap(x) is no solution. The repository is too big (1461MB) and exceeds the maximum size of the model. There is no EA running on the MS SQL server (and also I have no admin rights on the server), so transfer or native import directly is no option. I shall have to perform my action on the local network itself. It is a pitty that EA freezes during the process and that there is no manner to view the progress if EA has been frozen and there is no log available why EA stops. Only the eventlog shows that there was an error, but it give no information why.
Anyway, thank you for the tips. :)

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Native XML import (project transfer) non responsive
« Reply #4 on: June 08, 2020, 06:05:10 am »
Not sure if Jet4 would be of help?

Another way: have a Postgres instance where your SQL Server is and transfer a backup of your Postgres to to the very same as with the EAP.

q.

timoc

  • EA User
  • **
  • Posts: 201
  • Karma: +14/-0
    • View Profile
Re: Native XML import (project transfer) non responsive
« Reply #5 on: June 10, 2020, 11:21:33 pm »
i have been experimenting with is using a private git repository for transfer. Git compresses the XML, only transfers changes, and ensures transfer integrity. With gitlab or similar, it also minimises the bandwidth use over a company VPN.

I have been playing with this approach for a working from home model diff and merge process, its only working for a single user though.




Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Native XML import (project transfer) non responsive
« Reply #6 on: June 10, 2020, 11:42:52 pm »
Eap(x) is no solution. The repository is too big (1461MB) and exceeds the maximum size of the model.
Are you sure you need all that data?
1461MB is really big (if that is the corresponding .eap file size). Could it be that you have things like audit data or old package baselines that bloat the database?

To give you an idea
The biggest production repository at one of my clients is about 400 MB when exported to .eap.
It contains about 70.000 elements and 3.500 diagrams.

Geert

rmvanderlinden

  • EA Novice
  • *
  • Posts: 18
  • Karma: +0/-0
    • View Profile
Re: Native XML import (project transfer) non responsive
« Reply #7 on: June 11, 2020, 12:26:50 am »
In fact, our repository was even much bigger, but we removed all the components that we do not own. Also we restricted the model to our domain only. We have a landscape with more than 150 applications and the most of are integrated with each other. We mainly use BPNM, ArchiMate, UML. We make use of a library to reuse components/artifacts (avoiding duplication). Decreasing the size is a main topic (It should be nice if we could transfer to an eap(x) file again) but we will stick to 1 repository.
Nevertheless it should be nice when also big repositories could be transferred or Natively imported/exported without freeze/crash.

qwerty

  • EA Guru
  • *****
  • Posts: 13584
  • Karma: +397/-301
  • I'm no guru at all
    • View Profile
Re: Native XML import (project transfer) non responsive
« Reply #8 on: June 11, 2020, 12:27:21 am »
Not to forget (but often forgotten): EAP aka M$Access does not compact by itself. You need to do that manually on a regular basis.

q.