Server Mode on Apple Mac

[Nocton]

I run three databases in server mode all set up on Windows PCs using DACM's Quick Fix. Connection with PCs in different locations is via DropBox, as explained in previous posts. Now someone with an Apple Mac wants to connect. But looking at the Quick Fix instructions for setting up manually I see only instructions for 'file mode'. However, looking at my server mode setup I see that the Datasource URL is jdbc: hsqldb:hsql://localhost/;default_schema=true;get_column_name=false (instead of hsqldb:file:/users/public/databases/mydb/mydb;default_schema=true;shutdown=true;hsqldb.default_table_type=cached;get_column_name=false as given for file mode). So is that all I need to do, follow the manual instructions for file mode, but use the above Datasource URL?

Please advise, probably DACM, with any other suggestions re using an Apple Mac environment, e.g. replacements for the START.vbs and server.start.bat files, although the Apple Mac user thinks he can probably write replacements.

Regards, Nocton

[DACM]

I run three databases in server mode...on Windows PCs...Now someone with an Apple Mac wants to connect.

...looking at my server mode setup I see that the Datasource URL is jdbc: hsqldb:hsql://localhost/;default_schema=true;get_column_name=false.

So is that all I need to do, follow the manual instructions for file mode, but use the above Datasource URL?

...replacements for the START.vbs and server.start.bat files.

Hi Nocton,

Well, that particular 'server mode' URL is setup for a single-user ('localhost'), so assuming the Mac user will also participate in your Dropbox sharing scheme as a single-user, you could setup the Mac using the simple 'file mode' URL approach.

If you really want to run in 'server mode' then the data-source URL is only half of the equation. Some parameters are contained in the data-source URL, while other parameters are contained in the HSQLDB server startup string. Therefore, the server.start.bat and server.stop.bat files would require re-write for the Mac to control proper startup and shutdown of the HSQLDB server. Please share those script/batch files with us if your Mac user can produce them. The 'localhost' data-source URL you posted above should work on the Mac for a single-user with HSQLDB running in 'server mode'. The START.vbs simply runs the startup batch in silent mode under Windows (without opening a visible command-line window -- which then must remain open while the server is running). I'm not sure if there's a similar "silent mode" requirement on a Mac.

[Nocton]

Thank you, DACM. I'll aim to implement file mode as you suggest. I'll report back in due course, but it will be at least two weeks I expect as I am dependent on the Mac user getting on with the job.

Regards, Nocton

[Nocton]

Final query DACM re manual file mode,
The instruction given for Datasource URL is:
jdbc: hsqldb:file:/users/public/databases/mydb/mydb;default_schema=true;shutdown=true;hsqldb.default_table_type=cached;get_column_name=false

where .../databases/mydb/mydb specifies the location and name of your database files. That is clear, but for security and to comply with data protection legislation, since we hold lots of confidential information the database is located on an encrypted (Truecrypt) drive. So if the encrypted drive is T, the database files are located in T:\Databases\Run and if the name of the database is 'Encrypted' should the first part of the string be file:T:\Databases\Run\Encrypted
- probably not - but the question is how can I indicate that the application is not on the default/C drive?
(They are indeed backward slashes \ not the usual forward slashes /separating drive and folders??)

Regards, Nocton

[DACM]

...the database is located on an encrypted (Truecrypt) drive...the database files are located in T:\Databases\Run and if the name of the database is 'Encrypted' should the first part of the string be file:T:\Databases\Run\Encrypted

Actually, yes. Simply add the drive letter and colon to the data-source URL as you've done above. The slashes may or may not cause issues. The tutorial version uses forward slashes for compatibility with Linux. Windows doesn't seem to care (you can actually mix forward and back-slashes in the URL). Not sure about OS X (Mac), so experimentation may be in order (but then OS X is based on Linux).

...lots of confidential information the database is located on an encrypted (Truecrypt) drive

Cool, I'm a huge fan of Truecrypt, but just be aware that Dropbox can subvert your security efforts. That is, unless you use (mount) a Truecrypt container-file inside the Dropbox folder. So your distributed 'database' should be an encrypted Truecrypt container-file. Otherwise, a Dropbox folder hosted on an encrypted partition/drive is not secure because the files are uploaded to Dropbox in this case without Truecrypt encryption, since Truecrypt is de-crypting the files on-the-fly even for Dropbox. Dropbox files are encrypted (by Dropbox) but they're not truly secure in the event of a court order or a rouge Dropbox employee. So if you have any plain-text versions on Dropbox (encrypted only by Dropbox), you'll need to delete the old 'versions' saved by Dropbox as well. And before we leave the subject: HSQLDB 2.x, H2, Derby, and some others offer RDBMS-level encryption. Any encryption adds a layer of instability for your data, and I would trust Truecrypt's stability over all RDBMS-level encryption implementations. But due to Truecrypt's single password entry-point, the encryption provided by the RDBMS is far more secure and flexible for traditional multi-user environments. In other words, RDBMS-level encryption is more secure than a Truecrypt setup in multi-user environments with concurrent access.

[Nocton]

Many thanks, DACM. And for the additional information about using Truecrypt and Dropbox. However, for the level of security we need (it's only really addresses, and other contact details) we are happy to use Dropbox's level of security/encryption. No 'rogue Dropbox employee' is going to be interested in our stuff!

Regards, Nocton