Search the Community
Showing results for tags 'database'.
Hello. We are using Plastic SCM Cloud with Unity for 1,5 years now and database size is growing up by time, although our Repository size doesn't increase at all. This happens because the database (and cloud storage) keeps multiple versions of all assets. For example we have 50+ versions of our scene assets and they are really big. And we almost never need the older versions of scenes. We no longer need the histories of most assets from 1 year ago. We currently have 600 changesets but the changesets 1 to 400 aren't required anymore. As I know there was a trim command to delete old changesets from the database, but I couldn't find any info about this in the documentation. In example, to delete all changesets from 1 to 400 and database would look like it started in changeset 401, keeping all changesets to 600. And I guess we can backup and locally keep the original database from our disk. And if we ever need a file from those early changesets, we can access it with plastic using those backups. (From this directory: C:\Program Files\PlasticSCM5\server\jet) Am I correct with these? And if there is such an operation available, whats it called? Are there some best practices on what to do with such scene files that are changed often, but old versions aren't important? What should we do to avoid them growing the database size so fast? Thank you,
Hi all, according to https://plasticscmsupport.zendesk.com/hc/en-us/articles/360010163773-How-to-move-a-repository-to-a-new-Plastic-SCM-server there is an easy way to move a repository from one server instance to another. If you look at step 2 (Move the "jet/rep_2" folder to the new server "jet" folder): Is it possible to rename it in the same step e.g. to rep_1234? Is the string "rep_2" somewhere within the DB which will lead to problems when including that repo with following command? cm addrep rep_1234 core NEWSERVER:8087 Background: I want to move a repository from my local machine to the central server. There is quite a good chance that "rep_2" already exists on that machine. So I need to alter the number. Best regards Jan
If you ever face the following error: --------------------------- Error --------------------------- There has been an unexpected error "Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.". For more information check the server log. --------------------------- OK --------------------------- is because MySQL is not liking the default Plastic isolation level. You can change it by adding the following entry in your "db.conf" server config file: <IsolationLevel>RepeatableRead</IsolationLevel> "RepeteableRead" is OK, no issues are reported so far using it, this is the first one you will want to try if you face the error described above. If it doesn't work... contact us!
I've installed Plastic v18.104.22.1685 on a Windows 10 VM running on Mac - Accepted the default settings (including to use Jet back-end) and installation all went fine. I've started up the Plastic client, gone to create first repo, and I get an error which - strangely - references the Firebird backend: "...server wasn't able to open a connection to the database ... Error: The type initializer for 'FirebirdSql.Data.Common.Charset" threw an exception." I had an old installer on another machine for v22.214.171.1247 which I've installed successfully on another Windows 10 machine - so I uninstalled 1395, then installed 1307, but with the same result. Any ideas? Thanks, Steve. Additional info: I'm guessing this issue may be related to running Windows in a VM - if I change the server name from the suggested "Ghost.local:8087" to "localhost:8087", the repo is created successfully. But I still cannot progress any further without hitting the same database error.