Just installed DTPO2 and converted my old database. It exported 2599 items and imported 406 items. WTF? I’ve now got a database that contains less than 20% of the original. Upgrades are not supposed to create HUGE amounts of additional work. I’m going to reinstall DTPO1 and consider moving all the stuff off to another App. If I have to do the work I might as well try another system.
In fact all it’s done is import the folders - none of the data. This is worse than I first thought. What utter crap!
This is definitely not a Beta that you can release into the wild, and if DT claim that they have released this app to their schedule when the final version is still not available…
Oh, come on, stop whining. This is beta software. Your original file has not been changed at all, so you can just continue to work with it as you did before - where’s the problem? If the upgrade doesn’t work for you, just tell the developers, I am sure they will listen. But cursing and acting like a child is ridiculous. Get a life!
As far as I am concerned, the upgrade was very smooth. No lost files, no file names renamed, everything is working just fine.
I can understand being upset, but it is beta software. My upgrade went completely smoothly on two large databases. I’m sure all will be set right. If you want to use beta software, which, btw, the developers have made clear should be taken as such, you expect things to go wrong and you let the developers know. That’s how it works.
So let them know what went wrong, go back to using the old software until they set it right.
And other folks, use this as an example. You never want to delete your old version of software with a beta. Keep the old version around in case there are problems.
So far, not one crash, everything is perfectly fine data-wise for me.
“At the moment, DEVONthink and DEVONnote 2.0 have been released as public betas, pre-final versions that are stable and useable but are missing two or three planned features that will be added during the public beta phase.”
I don’t think it’s unreasonable to expect a “stable and useable” release, beta or otherwise, to be able to handle the basics of a data file conversion from an old format to a new format. Do you?
The developers monitor these forums and will be along with their input in due course and, hopefully, a resolution. I have posted so they know it is not only the OP who has the problem. In the meantime, as I have said, I’m off back to 1.5.4.
It hasn’t caused me any real problems like data loss and a quick reinstall of 1.5.4 gets me back to where I was but I am still not impressed. I simply expected more of DEVONtechnologies.
Wow, I’ve been away from this forum for a while. It’s qotten rather nasty over time. If your database is getting screwed up, then contact the developers and let them help you. No need to take it out on the rest of us. We are merely reporting that we had no problems. I’m sorry you did, so have the developers help you directly.
You aren’t going to like this… but I’ve managed to get mine working - for which I’m grateful.
The original set up had the file on a Droboshare set up, i.e. a Network Accessible disk. I moved the v1.5.4 database to the computer’s internal disk and tried again - this time it worked. I won’t say flawlessly, yet, but it looks as though everything is in the right place. The log only shows a list of PDFs that don’t have a text element to them - they haven’t been OCR’d, and those PDFs are in the database.
As I wasn’t entirely happy with the Droboshare’s performance I’m changing the set up so that the Drobo is directly linked to my main Mac and I’ll see how it works that way. I might get another Drobo set up and use it as a back up set up on the network.
All is now sweetness and light here, but it is good to remember that when something goes wrong it is extremely frustrating. At such times trite comments tend not to ease the situation but cause additional irritation. If nothing goes wrong for you and you haven’t experienced the frustrations, may I suggest that you don’t make a comment unless you can help, and that you take a few more risks…
This is the reason for the public beta period. Although DEVONtechnologies went through alpha versions, then 7 beta versions released to a beta test group of user volunteers, we are getting a few reports such as your initial report that at first seem mystifying, as such glitches hadn’t been previously encountered.
That’s because we can’t replicate, internally or with our beta testers, all the possible variables of hardware, network and software environments that appear in the larger community of users.
Thanks for identifying and solving the apparent cause of your initial problems. And yes, frustration can be very frustrating.
So we may have picked up a tip: If database conversion problems appear when the original database is on a network server, try moving it to the local computer environment for the conversion.
I think there may be some issues with the conversion process as I have written elsewhere. In one case, about 20% of the documents didn’t make it so I booted 1.5 from a clone drive and exported the files and then manually imported them into a 2.0 new database with no problems. When I tried that on some other 1.5 databases, the result was worse.
In the end, I am fairly sure that almost all documents made it over but if I had “mission critical” stuff, I would triple check to make sure everything is there.
As it happens, I’ve also managed to get mine sorted this morning.
My database is already on my internal HD so that wasn’t the cause of my problem. What was the cause was that I had all my documents locked. Unlocking them before installing DTPO2 allowed the conversion to complete successfully.
I agree, a simple ‘well mine works’ helps no one and would be better not said.
And another, if your documents are locked then unlock them BEFORE installing DTPO2.
I appreciate that but for something as basic and fundamental as converting data from an old format to a new format to not work at this late stage in the products development is not very good to say the least. It’s not as if a locked document is some hidden and rarely used option.
Anyway, we can debate all day as to whether the bugs identified in this thread should have been resolved before now but the fact is that they weren’t. The important thing is that they’ve been identified now along with the probable causes which should allow the developers to move quickly to fix them.
This is a problem that is typical for different working styles, I for example would have never tested with locked files … for the simple reason that I never lock files. But now DT knows about this (assuming you’ve told them) and they can fix it
Use the Ticket Process. They can’t be expected to read through every post in these forums… after all, this is a troubleshooting forum, not a bug report forum I’m sure they are aware of the problem, but it makes it easier on them to follow the procedure they begged us to follow.
I disagree, these are official support forums and they should be monitored to see what’s going on in them. They also make other users aware of problems and, if they’re affected, the potential solutions. The Ticket Process doesn’t have these benefits.
Having said all that, I was unaware of the Ticket Process and have now raised one as well to make sure that they are aware of the problem.
Disagree all you want. There are a lot of threads in these forums, and it’s unrealistic to expect that every thread will be monitored and seen by a DEVON developer. It may happen, but the signal:noise ratio isn’t all that good… ESPECIALLY for comments in the middle of threads.