TeamDesk Knowledge Base & Support

basenine 4/22/2015 6:12:21 PM

I'm not sure how many records you have on your database - but I'm not certain that number of records is the reason the timeout is occurring.

Yesterday, I was creating and promoting Dev branches pretty much all day. The database I was developing has over 30 000 records.
At one time, on one internet connection, I got a timeout when promoting the branch. When I swapped to another internet connection, the creation (whilst longer than the promotion) was pretty swift (maybe 30 seconds). Like I mentioned - I was creating/promoting all day (up to 15 times - 5 of which were in the last 1/2 hour).

Kirill Bondar  Staff  4/22/2015 6:16:58 PM

50 latest records is not a solution in case of interconnected tables - you may end up with new records in one table referring to old records in another table that won't be copied.

BTW, in new TeamDesk Backup and Restore Tools we've improved the restoration process to consume files produced by backup - make a copy of the app without data, make a backup of old application to some folder, run restore, select new app and point it to a backup folder; select tables to restore and have a cup of coffee :) - that's it.

cooper collier  4/22/2015 9:33:55 PM

I considered the backup and restore. The problem is the client has a crazy number of files. To make matters worse, when I made the database for them I gave them one file field. They started uploading files with different names into this ONE field, using the revisions as if they were different files! Without telling me (of course). This is likely what causes the copy database to fail.

The result is a restore will take hours and hours.


ps. I am fixing the document issue by making a document table. But the only way to migrate all the documents to the new table is for someone to manually download each document and re-upload it!

basenine 4/22/2015 10:04:37 PM

yeah - it'd be nice to be able to upload/import files easily....one by one gets a bit old!
Good luck, Cooper. 😀

basenine 4/22/2015 10:06:51 PM

you are aware that you can create a dev branch, then delete it if it's not what you want. The integrity of the active database isn't compromised then.

cooper collier  4/22/2015 10:46:51 PM

Yes the dev branch is the biggest best thing ever. I use it most of the time, but when I want to try something really crazy, I like the safety of a full copy. The first time we did a complicated table split, we practiced on a copy, thank god. We borked it up so bad, no amount of DEV branch would of saved us.

Once we get the stupid files moved, the backup restore should work just fine. We can just skip the document table.

Kirill Bondar  Staff  4/23/2015 2:45:10 AM

1. Files with identical content are stored once and reference-counted. Number of files is unlikely the reason the copy fails.
2. Devbranch does not copy data, it rather copies the structure to let you play with the copy. The data is shared and thus some operations are disabled.
3. Backup loads latest file version, that restore uploads. There is no ready-to-use solution to backup and restore whole revision history. With REST API the solution can be easily programmed using, say, Windows Scripting Host, Powershell or any other scripting language on any platform.