- Os x database client mac os x#
- Os x database client mac os#
- Os x database client code#
- Os x database client download#
I've also added a build for Sqlite 2.8.16 and 3.2.7 combined, for OS X 10.4).Net and the Mono Sqlite provider (Note: the Panther build uses Sqlite version 2.8.11.
Os x database client download#
I've put my build up for download it works on OS X Panther and hopefully on other versions as well. I modified the makefile to do this as an additional step. I looked again at Apple's notes and found that I had to create a bundle. I looked up Apple's notes on JNI, and found the library had to have an extension of.
Os x database client mac os#
I found out that some had reported problems with dynamic libraries on Mac OS X, so I rebuilt both Sqlite and the JNI wrapper with -disable-shared. The resultant makefile still wouldn't build. The configure script actually fell over with an error, but I found I could get it to run by specifying the location of the Java SDK and the Sqlite source. The Mac does use gcc and has autoconf, but clearly the author had not anticipated Mac usage. I revised it to enable the following defines:Īfter that it worked fine and all was well, on Windows at least. The reason is that the supplied Windows makefile is ultra-cautious about what is enabled. Because of this, even the test.java supplied with the project failed. This worked but I was puzzled to fnd that various functions were disabled although I knew they worked in the Sqlite source i was using (2.8.9). This failed at first, because a few source files have been added to Sqlite since the wrapper was last updated, so I added them in. Windows doesn't have GNU autoconf or automake, so Christian Werner supplies a makefile for Visual C++. The first problem I had came about when building the JNI library on Windows. Obviously it may fail if the Sqlite API changes, but so far all is good. You simply put the latest (or your preferred) Sqlite source in a subdirectory of his source, or specify the location of the source with an argument, and his JNI project will use that source. Christian Werner's configure script allows for this nicely. This makes them forks, albeit usually of a very minor kind, and you have the inherent fork problem of what to do when the main branch is updated.
Os x database client code#
Now, one of the problems with Sqlite wrappers is that many of them either include or modify the Sqlite code itself. It's a good project, and works exactly as expected on Linux: When it comes to Java, there is only one that I know of, and it is here. Fortunately many of the wrappers are themselves very small, so there is not too much to go wrong and you should be able to fix problems that arise. These range from finished code to various states of pre-alpha, alpha and beta. the main author), the same does not apply to all the wrappers out there. Note that while there's no doubting the qualiity of the Sqlite database library itself (kudos to D. I've also included some downloads for two things I found tricky - using the Mono Sqlite data provider with Microsoft.Net, and using the Java Sqlite wrapper on the Mac. What follows is a few notes on how I've got on so far.
Os x database client mac os x#
I was also interested in the possibility of porting the application to Java in order to run on Mac OS X and Linux, the two main "other" desktop platforms. I decided to investigate the feasibility of using Sqlite as an alternative to Microsoft's JET (the Access database engine) in a. Sqlite strikes me as nearly ideal for applications that need fast and robust access to local data. A SQL API is more portable, despite the dreaded implementation differences. So if you use the Codebase API and then later want to upscale to SQL Server or Oracle or DB2, everything will need to be redone. You can use SQL via its ODBC driver, but frankly ODBC should not be necessary for an embedded database. The problem with Codebase is that it is at heart Xbase and not SQL. It reminds me in some ways of Codebase, another excellent database library that runs everywhere. I like it because it is lightweight, fast, cross-platform, and supports a very decent subset of SQL.