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

[Paolo F Cantoni]

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.

How do you lock out?

We make the SQL Server DB single user (via SQL Management Studio), "kicking" everybody off.  We then do our dedicated processing.  Finally we restore Multi-user via SQL Management Studio.

Do you have any other technique?

Paolo

[qwerty]

We used a very old technique that requires opening and closing the mouth while producing certain sounds Additionally we assured that nobody was logged on. That was enough. For large (world wide) access one probably needs smarter procedures.

q.

[PeterHeintz]

Currently I lock the stuff as user (me), but honestly I have not jet investigated if this is reliable enough.

[Paolo F Cantoni]

Currently I lock the stuff as user (me), but honestly I have not jet investigated if this is reliable enough.

You mean <Context Menu> | Package Control > Lock Package locks (i.e. withihn EA?)

In our situation, we can't do that.  There are too many project roots and too many users with cross cutting access to do that.

Also, that doesn't lock some items under certain conditions - and our analysis of the repository security tables after using group locking suggests that it doesn't work properly, although we haven't tracked down what the issue is.

We have to use a more brute force approach.

Paolo

[qwerty]

Probably more Security/Lock. We did that too sometimes in similar contexts (though not necessarily for a project transfer).

If you have real issues you can disconnect the DB for general users and make the transfer locally to the machine.

q.

[PeterHeintz]

Hallo Paolo,
Yes, I use the features within Package Control.

I just have one root and two “EA-views” underneath, so what you have mentions is not a problem for my. If so, I would thing about to solve that problem with a script.

Another possibility I have in mind, is defining an “edit group” and assigning it to any user who is allowed to update some stuff, so I could just disable the update stuff in this group.
Both approaches I have not jet tested to be reliable, so there might be problems that these changes are only active when users reload the project or even restart EA, or maybe the script engine is ignored in those security features,….

Currently your “brute force” way, I could do as well. But the day will come when my IT will disallow me such “critical” things.

Another way I have in mind, is providing only Cloud Service access to the users. By doing so, I could lock out users by the Cloud Service (setting passwords, stop cloud server, …). Another advantage of that would be, that I would not need to give users write access to the DB. This would work fine I assume, if all EA features could be used over the cloud service.

[Geert Bellekens]

I have a client that decided to give users only cloud access because their internal security policy states that exposing direct database access over the network to client machines is not allowed.
Only Server -> Database access is allowed.
One way to follow this rule is to use the cloud service.
Another is to use Citrix or Remote Apps.

Both avoid having to expose your database on the complete network

Geert