Hello,

i searched the Forum, but i can't find the answer. Only somthing like: 'coming soon'. When is it 'soon'?
Does Elevatedb support OSX?

Thank you

Martin

>>When is it 'soon'?

Tim will have to answer that. I would like him to do it immediately!

>>Does Elevatedb support OSX?

The short answer is "No", you cannot include EDB components on non-Windows 32 projects, until the code is updated to exclude any links to Windows libraries. I think this is a big job.

However you can write a Datasnap project and build these for OSX. You then need to build a Datasnap server which serves the data. The Datasnap server has to run on a Windows computer which can be accessed by the Mac.

The Max would then use ClientDataset components (or other mechanisms) to access data.

>>The Max would then use ClientDataset components (or other mechanisms) to access data.

Max is plural for Mac (

Sanjeev wrote:

>>The Max would then use ClientDataset components (or other mechanisms) to access data.

Max is plural for Mac (


Max, ... OK

Thanks for your reply.
My Software is sometimes installed standalone and sometimes on up to 100 user in network. The database is only used like a catalogue and  readonly, so i used elevatedb embedded. Not as client/server. Because there are also standalone-computer a client/server system isn't practicable.

Is there another embedded db that supports OSX?

>Is there another embedded db that supports OSX?<

Sqlite. It is also supported directly by Delphi XE3 (XE2?) and later. It is the simplest to work with and no licensing to worry about.

Barry

Barry


I've only used SQLite a very small amount, and for a couple of small single user projects. I have read that its multi-use performance isn't brilliant. Do you have any input on the issue.

I'm using the Audcom components for data access (they're free) any other suggestions.

Roy Lambert

Roy,

>I've only used SQLite a very small amount, and for a couple of small single user projects. I have read that its multi-use performance isn't brilliant.<

That is correct, because Sqlite allows only 1 writer at a time. I believe it uses a database lock when a row is being updated.

However Martin said the database is ReadOnly so there won't be any writing from the 100 users so I don't see this being a problem.

Because he decided on an embedded database, then the biggest problem is the network and the size of the catalog table which will determine how much data is transferred over the network. This will be a factor for any non-client/server database.

For a list of Sqlite limitations, Martin he can look at https://www.sqlite.org/limits.html to see if Sqlite is suitable for him.

I personally would use a C/S database if there are more than 15-20 concurrent users or if the tables are larger than 100MB. Perhaps Interbase/Firebird would be better a better choice. It can be embedded but upgraded later to a C/S version.

Delphi XE5's FireDac supports FireBird 1.5 or later so that is something Martin may want to look at.
http://docwiki.embarcadero.com/RADStudio/XE5/en/Connect_to_Firebird_%28FireDAC%29

Barry

If Martin is really only looking to work read-only from the DB it would not be too much work to create a middle tier using a component like datasnap and then use clientdataset on the Macs.

The middle-tier programme would simply be a datamodule with a set of EDB tables or queries on it, and matching datasetproviders.

From the Mac side all that is needed is a SQLConnection component to provide a link between the middle tier and the clientdataset.

This would allow martin to stick with EDB "throughout", which I think I would find easier than introducing a new database.

According to Martin:
"My Software is sometimes installed standalone and sometimes on up to 100 user in network. "

so he needs a local database too. He could store TClientDataset locally as XML, but it won't be that fast for anything other than small tables.

Barry

Because of my good experience with ElevateDB I will return the support for OSX in my program and look forward to coming ElevateDB versions

Thanks for all replies.