Jim might correct me here, but I suspect the reason to avoid opening a Panorama X database direct from Dropbox (as opposed to storing it there, but copying it to a fixed location and opening that copy) is that a Panorama X database is not a single file but a package, which appears in the Finder as a file but is actually is a directory structure containing many individual files and folders.
When using Dropbox or other similar cloud storage solutions such as NextCloud, the desktop client maintains a mirror, in a dedicated directory on a local drive, of the files stored in the cloud. Any changes made to the local copy are automatically mirrored to the cloud copy and vice-versa. However, this process does not happen instantaneously. When a single file such as PNG or a ZIP archive is mirrored in either direction, either the old or the new version will be available in any location at any point in time and there is no ambiguity. The same goes for something like a Microsoft .docx file which is a directory structure saved in a ZIP archive: the archive is a single file, thus an attempt to open it will always find either the old or new version complete. But to Dropbox, a Panorama X database package is nothing special, just a normal directory containing many files to be mirrored one-by-one. Every time the database is saved — and of course macOS auto-saves frequently — the local copy is updated quickly but the remote mirror will catch up more slowly, and until it has completed it will be in an indeterminate, effectively corrupted state, containing a mixture of old and new files. Similarly if the remote server contains a later version than the local copy: during the process of mirroring from the former to the latter the status of the local copy will be indeterminate — there will appear to be a Panorama X package there, but its internal file structure will not be valid until mirroring is completed. Thus any attempt to open it during that process might either fail or, worse, lead to more insidious problems that don’t come to light until too late, after that damaged version has been resaved.
Most of the time this will not happen, because if a database is only used on one machine at a time, during that session it will be opened from and saved to the local copy only; all mirroring will be from that to the remote cloud copy, and it will only be the local mirrors on other machines sharing that Dropbox folder that might be in an indeterminate state while they catch up with the remote mirror. However, there is the potential for things to go wrong because, with Dropbox controlling the folder in which the database resides, you can’t completely guarantee that the local copy will always be in a stable state when opening or saving.
Hence it is safest to copy/move the database from the Dropbox mirror folder to a normal folder which Dropbox doesn’t control, open that copy, and copy/move it back to the Dropbox folder after it has been saved and closed.