I was checking the Web Server preferences and since there was an option to launch the web server at startup, I was wondering why the the DTPO application had to be running in order for the client computer to connect to the web server? Isn’t that the point of starting the web server when the computer is booted? Or do I have a problem with the program configuration?
I am running DTPO version 1.5.4 (I wasn’t able to export my database to the dtBase2 format, and had to roll back to version 1.x).
Thanks in advance,
Yes, the database(s) to be shared via the Web server have to be open under DTPO2.
There are two steps to Web sharing:
Click the button to Start Web sharing under DTPO2 Preferences > Server. If desired, Start can be enabled automatically when the application is launched.
For each database to be shared, choose File > Database Properties and check the option, Share Database. That user choice will be remembered when the database is opened.
Thus, one can choose which databases are to be shared, and which are to remain private. For example, I can keep my Financial database open, but private, while sharing other open databases.
I was using both version 1.5.4 and 2, and I was able to get the web server working. I was just suffering from wishful thinking, and was hoping to see this work without having to run the DTPO program . I understand.
I take it from your comment that version 2 supports more than one database being open concurrently. I’ll check on version 2 in a few months, or when the next beta is relased. I cannot export my database to vresion 2 withouth the program crashing. I see on the forums that this is a common issue.
I wasn’t saying that I was using Apache. I was using the DTPO web server. I was suffering from “wishful thinking,” and was hoping for a way to not have to open the database in DTPO.
I haven’t seen evidence in forum reports or in Support messages that crashing of DT Pro/Office 2.0 pb1 is a common problem.
There are reports of incomplete conversions of databases, and of several cases in which PDFs were renamed during conversion. In such cases the developers hope that there is an associated crash log submitted by the user, as that can make it easier to diagnose the problem.
I’ve gone through a series of 9 versions of DT Pro Office 2.0, hammering away at each one as hard as I could. I haven’t been able to make the application crash since a very early pre-release beta. I experienced a total of three crashes, all of which involved a particular WebArchive file that had unusual characteristics. Christian adapted the program to accept that exceptional file. I haven’t been able to make the application crash, since.
I’ve got a lot of databases, and conversion of them to the version 2 database format has been going smoothly.
But – and this is a big but – I run under a pretty stock version of OS X 10.5.6. I don’t have any Input Manager plugins, Unsanity haxies, Safari add-ons or similar modifications of OS X installed; my operating system is very stable. I don’t have problems resulting from power outages or brownouts that could result in data corruption during a write-to-disk. Periodically I run routine OS X maintenance. So my computer is a pretty good environment for being able to distinguish bugs in an application from problems that result from a damaged OS X, such as memory errors or damaged operating system code.
From the earliest days of DEVONthink we have seen problems that result from installation of the kinds of software that modify the operating system, such as Unsanity haxies. Most of the time, things may run smoothly, but sometimes things go very wrong because of modifications to OS X.
When such problems occur, one of the best ways to isolate the offending software is to create a new User account that doesn’t have any hacks to the operating system. If everything is running smoothly, start adding in the suspect software one by one.
My intention is not to knock this product; if anything, I feel the contrary is true. I was merely suggesting that there are users with migration issues. In my case, the error was coming up as “…/DEVONthinkPro_DB.dtBase2/Files.noindex is out of space.” The volume didn’t have a tremendous amount of free disk space, maybe 180 GB free at the time I started the migration.
I rolled back to v1.5.4 and and have had no issues since. I will check for the next beta and see how I fare…
You do bring up a valid point regarding the testing with a different user account that has no unnecessary junk running like my account! I will have to try it out and see what happens. But it isn’t a big thing, and I can still use the older version. Now if version 2.0 goes GA and I’m still having these problems, it will be a bigger deal!
I do have a question for you. How big are your databases? The one I’m trying to migrate is up to 45 GB. I have three backups and and convert directory (in itself is 8.5 GB) in the DEVONthinkPro_DB.dtBase package.
My database sizes: I’m managing well over 150,000 documents in a number of topically-designed databases. With a couple of minor exceptions, they are self-contained (no Index-captured content). My original reason for using topically-designed databases was to keep them running quickly on my 1 GB RAM TiBook, years ago. But I’ve also found that this improves the focus of searches and See Also operations.
My main database —the one most often used for research and writing, runs 5.96 GB in the database 1.x file format, and 2.41 GB in the version 2.x database format. I’ve got an ancillary related database that contains more strictly technical documents such as chemical analytical procedures, sampling protocols, data evaluation protocols and the like, that’s of comparable size. Occasionally I need to search across both. That’s easy under DEVONthink 2.
Version 1.x databases can vary widely in size and in memory required to open the database for the same content in text and images, depending on the filetype of documents. For example, a database containing that content in RTFD will be substantially larger than a database with the same content in PDF. That’s because the images are stored in memory for the RTFD documents (and also repeated in each of the internal Backup folders), but that’s not so for the PDF documents.
Version 2.x databases essentially eliminates those differences related to filetype, as all documents are stored in Files.noindex inside the database package file, regardless of filetype.
Reported problems in converting databases: Yes, that’s why this is a beta release. The developers are evaluating such reports. Some may result in changes to DEVONthink 2. Others, that result from instability on the user’s computer, may require correction at the user’s end, such as removal of software that damages OS X.
There are significant code changes in DEVONthink 2 (compared to DEVONthink 1.x), optimizing it for Leopard and incorporating new features that are Leopard-only.
We would be interested in the results of your experiment with a clean (unhacked) operating system using a new User account that doesn’t contain your Unsanity haxies. In any case, it will be interesting to see if those haxies still run under Snow Leopard (OS X 10.6.0), expected in a few months. Snow Leopard promises significant performance improvements for owners of Intel-based Macs.
I will try the migration using a clean user account (that doesn’t have any haxies loaded), and report back. Regarding the Unsanity software, I would think that OS X 10.6 will result in Unsanity releasing a new round of beta code in order for their programs to run under 10.6. This is made more interesting because some of their “current” releases are still in beta for OS X 10.5.
I ran the migration from a user account that loaded no Unsanity Haxies. This was a minimal user configuration, with very little running (it anything) from startup items (I do realize that there are other ways to load items at start [or boot]).
OK, I ended up wit a slightly different outcome, but the end result was still failure. This time around it didn’t complain with error message “…/DEVONthinkPro_DB.dtBase2/Files.noindex is out of space.” Instead, it seemed to process all the data, even though the log of the operation showed there were
. I understand.