The beta looks excellent. I’m looking forward to getting the hang of all the new features.
One problem I’ve noted: I imported my old database, and many (perhaps most) of the documents have lost the titles I gave them. They have been automatically numbered, so that each Group now has 000001.pdf, 000002.pdf etc. How can I import the database so that this doesn’t happen?
I noticed the renaming on import but checking the package contents/Files.noindex folder I see the files have the names I gave them.
Re: documents losing the names assigned to them under DEVONthink 1.x
Haven’t encountered this, nor do I recall such a problem found by our beta test group.
I hadn’t converted a database with the public beta version released today, so just did so. All files in the converted database retained the names from the DT Pro 1.x database, including several hundred PDFs. Previously, using private betas, I’ve converted databases containing tens of thousands of documents without any such problem.
Had you recently run Verify & Repair on your DT 1.x database? It’s a good idea to do that before conversion, as a database with any glitches would cause problems.
Bad news… your suggestion didn’t sort it out.
I deleted the new databases.
Then I opened the old database in DT 1.x.
Then I ran verify and repair, and then I ran rebuild.
Then I closed DT 1.x, and opened DT 2 beta, and attempted to import the newly verified and rebuilt database.
It goes through its work without complaint, but it renames all of the pdfs with those numbers.
I just reopened my DEVONthink Pro and my document names were present this time.
Just before opening the DTP document, I checked the finder versions. Don’t know whether that could mean anything
Me too. I tried it yet another time, and it worked fine. Which is great for me, but not so great for the beta testing project, since I can’t tell you what happened the third time around that made it work.
Could anyone send a small & zipped database demonstrating the problem to support - at - devon-technologies.com or to ftp:/ftp.devon-technologies.com/incoming? Then I’ll check this over here.
Same here - followed instructions (in the pdf), then
-created an additional backup of the main database (15 GB)
-placed it in another drive
-moved the old DT app out of the Applications folder
-dragged new DT2 to the Apps folder
-created a very small new test database
-pointed DT2 to my existing DT1 main database - which resides in another drive
-DT2 popped a message saying it had to export then reimport the database
-while reimporting, which is still going on - I can see ALL files being flashed as “0001.pdf, 006.rtf” and so on. Not a single of the original filenames.
I hope this is not a bad sign
I still have DT1 and backups, in any case.
Here’s an image of what I was referring above…
As I mentioned earlier I saw this too. Did you go to the files in the Finder (DT app/show package contents/Files.noindex) to see what names they had after the import? Mine were in all sorts of new folders but had the names I gave them.
I checked Files.noindex. All my PDF files (~2300) were renamed as numbers. I did the import twice, I’m going to try and do it one more time.
My RTF files retained their names however.
OK, that is weird then. I wonder how mine stayed the same.
I, too, saw this happening during an import from a 1.5.4 database. I was seeing exactly what uimike has in the screenshot. I had already read some of the comments on these forums and how this was a problem, so I forced quit DTPO and re-installed 1.5.4. Then, I exported my database manually (not all at once, but I have about 6 or 7 top-level groups which I exported individually). I then re-installed DTPO 2 beta and imported. This seems to have preserved all original file names as they appeared in the 1.5.4 database.
Did it preserve replicants?
No. Converted them to duplicates, which isn’t a huge problem as I didn’t have that many.
Tried uninstall (via AppZapper) DT and DT2. Reinstalled DT. Verified, Optimized, and Rebuilt the database. Installed DT2. Import showed a bunch of “failed” messages again and renamed all my files to the 000000x.pdf format. Opened up DT and exported the folders that I had. Imported them with DT2 and everything looks good so far.
So, if all else fails an export and import might work. I don’t use replicants or duplicates so that wasn’t an issue for me.
Well, after a few hours, and the strange export/import filenames, I am really happy to report that the 20 gig (main) database was totally perfectly imported into a 12 gig DT2 database, complete with duplicates and replicants. The only casualty was I had customized my labels, but hey, that’s 1 minute
Then I did the same to the other, smaller databases, and I’m a happy man!
DT2 is much faster, and the retooled browser flies.
KUDOS to DT!
I saw the same thing as DT 2 was creating the new database. I thought I was screwed as my database contains many Papyrus .pap.pdf files that I edit daily. I was quite relieved to see all the file names intact at the end of the process. Everything displays & edits just fine and I can see my Excel files too. Major bonus
I am experiencing the same problem. I have also verified, optimized, and synchronized the database in DT 1.5.4 before converting. After opening the database in DT 2 and converting, the filenames for pdf’s, images, etc are all renamed to: 000001.pdf, 000002.pdf, etc. Numbering restarts for each group. This happens both for files that are imported into my DT database and for files that I have indexed.
I have 40 Gb free space on my HD. My database is 5 Gb big and has around 6500 posts.
For my indexed files: When I synchronize a group in the newly converted database, I get new posts with the original filenames, but the old posts with the numbers are retained - so I end up with double posts for each indexed file, one with the correct name and one with a number. I could manually delete all the wrongly named doubles (this would take a couple of hours), but this would not help me for my non-indexed files that are imported into DT.
I have tried converting 5 times now (first time before optimizing the database). The same error occurs each time. I really hope you find a solution soon.