Prj Transfer „Database has reached maximum size [Select * from t_snapshot] Field

[PeterHeintz]

We have a EA SQL repository that is transferred to a eap file regularly.

Now we get the following error message:
„Database has reached maximum size [Select * from t_snapshot] Field:bincontent2”

As I know MS-Access DB’s are limited to 2GB. The last successful transfer resulted in ~800 MB. To verify that the data in the SQL DB is not exploded, we transferred the data to a feap, again resulting in ~ 800 MB.
So we are still far away from 2 GB.

Any idea on that?
And
Does anyone know if the transfer is done with one SQL select transaction?

[Geert Bellekens]

it's probably the blob in the bincontent that is too big to be transferred to .eap.

workaround could to start from a backup of your SQL Server, delelete the baselines (which is what I think is in the snapshot table) and then try to transfer to .eap

Geert

[PeterHeintz]

You mean the internal model baselines are stored in the bincontent2 and the bincontent2 field has restrictions to be << 2GB, right?

I saw that the BinContent2 is of field type OLE-Object that is limited to 1 GB.
However if the whole thing is ~ 800 MB the baseline parts should not be > 800 MB. Further on I belief to remember that the baselines are stored somewhere else.

Could be that the whole model is stored in that t_snapshot field before the data goes to the final tables. And maybe this whole model OLE exceeds the 1GB limit for some reasons.

[Uffe]

Hi,

Just a quickie -- it's not baselines. Baselines are in t_document, with DocType "Baseline".

/Uffe

[Uffe]

... It's audit logs.

You could try saving the audit logs, then deleting those logs, transferring the project and loading the logs back in.

Please note that I've no idea if you can successfully restore audit logs after a project transfer. But if you're stuck, it might be the only way forward.


/Uffe

[Geert Bellekens]

Hi,

Just a quickie -- it's not baselines. Baselines are in t_document, with DocType "Baseline".

/Uffe

I stand corrected then, it's the audit data that is stored in t_snapshot isn't it?
In that case you can save the audit data for a specific period (which you probably better do each month or so anyway) and then clear the audit logs before transferring the model.

Geert

[Uffe]

Quick! Look behind you! 

[PeterHeintz]

Thank you both!
I asked our project responsible and indeed they have enabled audit log (more by mistake).

It is still not clear to me why 800 MB with audit logs can contain 1 GB audit logs, or in other words, how 800 MB can contain 1GB.
Anyhow, if clearing and disabling the audit log will solve that issue I am not keen to get behind that mystery.

Do you have also an idea about my “one SQL select transaction” question.

It is just not clear to me if we should switch our users to read only when transferring, to avoid model inconsistency.

[qwerty]

Peter, you should ask Sparx about this - and post the answer (unless a quick Sparxian will post the answer directly here).

q.

[PeterHeintz]

Yes, I agree.
I just wait a few days to see if Sparx give some feedback.

[Geert Bellekens]

Do you have also an idea about my “one SQL select transaction” question.

Model transfer does not work in a single transaction.
I once had an issue at a client where there was an error when transferring the model and a none of the attributes were transferred (and none of the tables that should have been transferred after t_attribute).
The tricky thing was that this was only discovered after a few days, so we had to "manually" move the contents of those few tables. (and unload/reload story IIRC)

Geert

[qwerty]

When we did a transfer it was also in night hours when nobody was online. But having a short confirmation from Sparx would be good.

q.

[PeterHeintz]

Yes, would be!
Our projects do not have nights at all!

[PeterHeintz]

Just to bring the main part of that issue to the end!
Clearing the audit lock finally solves the problem being not able to do the transfer.

[PeterHeintz]

Here is the response from Sparx about my “One SQL select transaction” question.

“The data is read over time.”

So from my point of view, it is very recommended lock out the users with write access when doing long transfer, baseline, import/export stuff.