SQLite

SQLite 3.6.12 for OS/2 ---------------------- This is a port of the SQLite embedded SQL database library, v3.6.12, to OS/2. Please see http://www.sqlite.org/ for more information about SQLite, include the documentation. Dependancies sqlite3.exe requires the EMX runtime environment - v0.9d at least. Installation 1. Copy sqlite3.exe (in the bin subdirectory) to a directory on the PATH (sqlite3va.exe and sqlite3ow.exe don't include the readline library support, but also don't depend on the EMX runtime; you may copy either instead of, or in addition to, sqlite3.exe if you wish). 2. Copy sqlite36.dll to a directory on the LIBPATH, or make sure that you use BEGINLIBPATH or ENDLIBPATH appropriately. 3. If you intend compiling your own SQLite code, copy the contents of the include and lib subdirectories to locations appropriate for your development tools. Documentation Please refer to http://www.sqlite.org/ Source The src subdirectory contains the Makefile, module definition file, and a patch file with the changes to the original sources that adds support for non-EMX compilers. Note that this port is based on the amalgamated source (ie 1 source file - sqlite3.c) release distributed as sqlite-amalgamation-3_6_12.zip, with the shell source taken from the standard v3.6.12 source tarball. Using the amalgamated source simplifies the makefile considerably, though in my experience the performance gain which the SQLite authors claim arises from better optimisation possibilities using this technique are negligible with the compilers I use. YOU HAVE BEEN WARNED 1. While the build infrastructure requires the EMX 0.9d toolchain, the DLL (sqlite36.dll) has been built as a standalone DLL (-Zso -Zsys EMX gcc options) so is not dependant on the EMX runtime. In consequence, the library should be able to be used from any development environment that can call OS/2 DLL APIs with the System calling convention. The library has been compiled with multithread support (-Zmt), and the sqlite API is fully multithreaded, with certain restrictions (see the SQLite documentation for more information). See item 5 below for more information about using the DLL with other compilers. 2. This port is still restricted to 2GB file sizes :-( 3. I have enabled the fts3 and rtree SQLite extensions - please refer to the documentation at http://www.sqlite.org/ for more information about this functionality. I would have liked to also enable the icu extension, but that will require a bit of work to sort out the Unicode interface. 4. [for developers] As a consequence of the DLL being built as a standalone DLL, care must be taken about releasing memory allocated by SQLite calls. There are some SQLite API functions that allocate memory for which responsibility of deallocation is assigned to the caller. The sqlite3_free() function is used for this purpose - free() should not be used for such memory, as your application's runtime memory allocator won't have any record of the memory and using free() will have undefined (and probably unwanted) results. 5. [for developers] include/sqlite3.h has been modified to include support for compilers that don't use the _System calling convention by default, such as VisualAge C++ and OpenWatcom - see the sqlite3.h.patch file in the src subdirectory for the changes made from the standard sqlite3.h. The files sqlite3va.exe and sqlite3ow.exe in the bin subdirectory were compiled with VisualAge C++ 3.65 and OpenWatcom 1.7a respectively, with only minor modifications required for compilation to succeed (though both the binaries lack readline support); the shell.c.patch file in the src subdirectory contains the necessary changes. An important consideration highlighted in the shell.c patch is the necessity for declaring callback functions as using the _System calling convention, when using compilers other than EMX's gcc. Be warned however that OpenWatcom (1.7a at least) has some level of incompatibility with the EMX toolchain for the function sqlite3_vmprintf(). The va_list implementation differences between the toolchains are significant enough that the 2nd and subsequent variable parameters are received incorrectly by the DLL function (the 1st variable parameter is okay). VAC++ 3.6.5 doesn't appear to have the same problem. I haven't yet attempted to use Innotek's gcc toolchain with this code, though others have (without the patches in this port). 6. This release has had only cursory testing. Caveat utilitor.... Note that there is a very rudimentary test harness in the src subdirectory - read src/test_notes.txt for more information. Credits Daniel Kruse and Peter Weilbacker have been doing the lion's share of keeping SQLite supported on OS/2. Peter has merged as many of the changes to support the EMX, VAC++ and OpenWatcom toolchains as is practical. Thanks to you both! Support OS/2 specific issues, such as applications abnormally aborting or issues with building applications on OS/2 with this port, can be addressed to me at the email address below though as I didn't write most of the OS/2 code in this release I mightn't be that much help :-| Issues with SQL or other general behaviour should be directed, at least in the first instance, towards SQLite's author(s) - see the SQLite home page noted above for contact details. Note that SQLite's authors may not be able to help with OS/2 specific issues, though they should be able to forward any issues to the contributor of this support. Legal matters This software is provided 'as-is', without any express or implied warranty. In no event will the packager be held liable for any damages arising from the use of the software. The SQLite code has copyright disclaimed. I quote from the source file src/main.c: /* ** 2001 September 15 ** ** The author disclaims copyright to this source code. In place of ** a legal notice, here is a blessing: ** ** May you do good and not evil. ** May you find forgiveness for yourself and forgive others. ** May you share freely, never taking more than you give. ** ************************************************************************* ... Andrew MacIntyre email: andymac@bullseye.apana.org.au, or andymac@pcug.org.au web: http://www.andymac.org/ 13 April, 2009.

SQLite 3.6.6.1 ^^^^^^^^^^^^^^^^ This is a test release of the SQLite 3.6.6.1 library and shell frontend. - What is SQLite From the project website (http://www.sqlite.org/): SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. It is used in countless desktop computer applications as well as consumer electronic devices including cellphones, PDAs, and MP3 players. The source code for SQLite is in the public domain. - Files in this release: For simple uses the SQLite shell should be enough, but in case someone wants to write a program using the SQLite library, I included the DLL and an import library. For users: sqlite3.exe the shell frontent (without readline support) sqlite36.dll the SQLite library DLL For developers: sqlite3.sh the shell script used for compilation sqlite36.def the linker definition file for used for the DLL sqlite36.lib the library import file, for linking against the DLL sqlite3.h the SQLite C header file sqlite_demo.c demo program from http://www.sqlite.org/quickstart.html - Runtime requirements To be able to run the program you need: libc063.dll This SQLite release was compiled using GCC 3.3.5, so it requires the kLibc C runtime library v0.6.3. Get it from ftp://ftp.netlabs.org/pub/gcc/ uconv.dll It uses the OS/2 Unicode Conversion Functions, to convert filenames from the system codepage to UTF-8 and back. This library is present on any modern OS/2 system. Opposed to earlier releases of this library, any version should work. - Usage The SQLite webpage contains usage instructions, see especially http://www.sqlite.org/quickstart.html for some first hints. As explained there, the executable is already useful on its own to create database tables. More detailed documentation of this program can be found here http://www.sqlite.org/sqlite.html If you want to link the SQLite library into your own program that should be easy, too. For testing, I copied the demo C program from the quick start page and included it in this package as sqlite_demo.c. To compile use gcc -Zomf -Zexe -I. -L. sqlite_demo.c -lsqlite36 In case you just want to look at some SQLite databases, I recommend to use the sqlitebrowser tool. It combines the SQLite engine with a simple to use UI frontend. Get it from Hobbes: http://hobbes.nmsu.edu/h-search.php?key=sqlitebrowser - Legalities SQLite is public domain software. This package is provided "as-is", if it does something bad to your computer or the data on it, don't hold me responsible. Peter Weilbacher <mozilla@Weilbacher.org>, 2008-11-22

SQLite 3.4.2 for OS/2 --------------------- This is a port of the SQLite embedded SQL database library, v3.4.2, to OS/2. Please see http://www.sqlite.org/ for more information about SQLite, include the documentation. Dependancies sqlite3.exe requires the EMX runtime environment - v0.9d at least. Installation 1. Copy sqlite3.exe (in the bin subdirectory) to a directory on the PATH (sqlite3va.exe and sqlite3ow.exe don't include the readline library support, but also don't depend on the EMX runtime; you may copy either instead of, or in addition to, sqlite3.exe if you wish). 2. Copy sqlite34.dll to a directory on the LIBPATH, or make sure that you use BEGINLIBPATH or ENDLIBPATH appropriately. 3. If you intend compiling your own SQLite code, copy the contents of the include and lib subdirectories to locations appropriate for your development tools. Documentation Please refer to http://www.sqlite.org/ Source The src subdirectory contains the Makefile, module definition file, and a patch file with the changes to the original source, and a patch to the generated sqlite3.h header that adds support for non-EMX compilers. Note that this port is based on the amalgamated source (ie 1 source file - sqlite3.c) release distributed as sqlite-amalgamation-3_4_2.zip, with the shell source taken from the standard source tarball. Using the amalgamated source simplifies the makefile considerably, though in my experience the performance gain which the SQLite authors claim arises from better optimisation possibilities using this technique are negligible with the compilers I use. YOU HAVE BEEN WARNED 1. Peter Weilbacher merged most of the changes in the 3.4.0 port back into the SQLite SVN tree. The significant exception being the extensive changes to sqlite3.h for calling convention support with the VisualAge and OpenWatcom compilers. Thanks Peter! 2. A small "correctness" fix made to the master sources exposed some problems in the OS/2 file lock acquisition code. My fixes to these issues account for nearly all the changes in the patch to sqlite3.c. 3. While the build infrastructure requires the EMX 0.9d toolchain, the DLL (sqlite34.dll) has been built as a standalone DLL (-Zso -Zsys EMX gcc options) so is not dependant on the EMX runtime. In consequence, the library should be able to be used from any development environment that can call OS/2 DLL APIs with the System calling convention. The library has been compiled with multithread support (-Zmt), and the sqlite API is fully multithreaded, with certain restrictions (see the SQLite documentation for more information). See item 5 below for more information about using the DLL with other compilers. 4. [for developers] As a consequence of the DLL being built as a standalone DLL, care must be taken about releasing memory allocated by SQLite calls. There are some SQLite API functions that allocate memory for which responsibility of deallocation is assigned to the caller. The sqlite_freemem() function is used for this purpose - free() should not be used for such memory, as your application's runtime memory allocator won't have any record of the memory and using free() will have undefined (and probably unwanted) results. 5. [for developers] include/sqlite3.h has been modified to include support for compilers that don't use the _System calling convention by default, such as VisualAge C++ and OpenWatcom - see the sqlite3.h.patch file in the src subdirectory for the changes made from the standard sqlite3.h. The files sqlite3va.exe and sqlite3ow.exe in the bin subdirectory were compiled with VisualAge C++ 3.65 and OpenWatcom 1.7a respectively, with only minor modifications required for compilation to succeed (though both the binaries lack readline support); the shell.c.patch file in the src subdirectory contains the necessary changes. An important consideration highlighted in the shell.c patch is the necessity for declaring callback functions as using the _System calling convention, when using compilers other than EMX's gcc. I haven't yet attempted to use Innotek's gcc toolchain with this code, though others have (without the patches in this port). 6. This release has had only cursory testing. Caveat utilitor.... Note that there is a very rudimentary test harness in the src subdirectory - read src/test_notes.txt for more information. Support OS/2 specific issues, such as applications abnormally aborting or issues with building applications on OS/2 with this port, can be addressed to me at the email address below though as I didn't write most of the OS/2 code in this release I mightn't be that much help :-| Issues with SQL or other general behaviour should be directed, at least in the first instance, towards SQLite's author(s) - see the SQLite home page noted above for contact details. Note that SQLite's authors may not be able to help with OS/2 specific issues, though they should be able to forward any issues to the contributor of this support. Legal matters This software is provided 'as-is', without any express or implied warranty. In no event will the packager be held liable for any damages arising from the use of the software. The SQLite code has copyright disclaimed. I quote from the source file src/main.c: /* ** 2001 September 15 ** ** The author disclaims copyright to this source code. In place of ** a legal notice, here is a blessing: ** ** May you do good and not evil. ** May you find forgiveness for yourself and forgive others. ** May you share freely, never taking more than you give. ** ************************************************************************* ... Andrew MacIntyre email: andymac@bullseye.apana.org.au, or andymac@pcug.org.au web: http://www.andymac.org/ 27 December, 2007.

SQLITE: ======= SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. The sources are in the public domain and can be used for any purpose. The database is stored in a file and portable across platforms! ABOUT THIS PORT: ================ This is a quick and dirty build of SQLite v3.3.13 for OS/2 and eComStation and has not been fully tested. It doesn't include a sqlite3.dll nor does the executable sqlite3.exe support Tcl/Tk! It's planned to create the sqlite3.dll in the (hopefully not to distant) future. I'm already working on it (the *.DEF file). I'm not responsible for any damage this program may cause on your machine. There is a DEBUG version and an optimized version (without debug information) available. The release version is much smaller than the debug version. SQLite has been build using GCC 3.3.5 CSD1! The version included in the DEBUG directory has been created from the sqlite-source-<version>.zip (archive containing pure C source code for the SQLite library). I had to add another include command at the os2.h to build the executable. I used the the following lines of my little build script to build the DEBUG version: ====BUILDOS2.CMD==================================================== IF EXIST buildreport_*.txt del buildreport_*.txt cd src IF EXIST *.a del *.a REM GCC object files IF EXIST *.o del *.o REM Watcom object files IF EXIST *.obj del *.obj IF EXIST *.err del *.err IF EXIST *.exe del *.exe IF "%2" == "" for %%1 in (*.c) do gcc -g -O2 -c %%1 >> ..\buildreport_gcc.txt 2>&1 del shell.o ar cr libsqlite.a *.o ranlib libsqlite.a gcc -o sqlite3.exe shell.c libsqlite.a ==================================================================== The release version has been created by simply running the configure and make from the complete source code tarball (sqlite-<version>.tar.gz). As said above it hasn't been tested very much. FURTHER INFORMATION: ==================== http://www.sqlite.org/ USAGE: ====== Try the quick start "SQLite in 5 minutes or less": http://www.sqlite.org/quickstart.html AUTHOR OF THIS PORT: ==================== Juergen Ulbts http://www.juergen-ulbts.de/ Feb/March 2007

SQLite 2.8.16 for OS/2 --------------------- This is a port of the SQLite embedded SQL database library, v2.8.16, to OS/2. Please see http://www.sqlite.org/ for more information about SQLite. Dependancies sqlite.exe requires the EMX runtime environment - v0.9d at least. Installation 1. Copy sqlite.exe (in the bin subdirectory) to a directory on the PATH (sqlite_va.exe and sqlite_ow.exe don't include the readline library support, but also don't depend on the EMX runtime; you may copy either instead of, or in addition to, sqlite.exe if you wish). 2. Copy sqlite28.dll to a directory on the LIBPATH, or make sure that you use BEGINLIBPATH or ENDLIBPATH appropriately. This version of the DLL should be a dropin replacement for previous 2.8.x releases. 3. If you intend compiling your own SQLite code, copy the contents of the include and lib subdirectories to locations appropriate for your development tools. Documentation The doc subdirectory contains the SQLite README, manpage (sqlite.1), and HTML documentation. Source The src subdirectory contains the Makefile, module definition file, and a patch file with the changes to the original source, and a patch to the generated sqlite.h header that adds support for non-EMX compilers. YOU HAVE BEEN WARNED 1. While the build infrastructure requires the EMX 0.9d toolchain, the DLL (sqlite28.dll) has been built as a standalone DLL (-Zso -Zsys EMX gcc options) so is not dependant on the EMX runtime. In consequence, the library should be able to be used from any development environment that can call OS/2 DLL APIs. The library has been compiled with multithread support (-Zmt), and the sqlite API is fully multithreaded, with certain restrictions (see the SQLite documentation for more information). See item 4 below for more information about using the DLL with other compilers. 2. [for developers] As a consequence of the DLL being built as a standalone DLL, care must be taken about releasing memory allocated by SQLite calls. There are some SQLite API functions that allocate memory for which responsibility of deallocation is assigned to the caller. The sqlite_freemem() function is used for this purpose - free() should not be used for such memory, as your application's runtime memory allocator won't have any record of the memory and using free() will have undefined (and probably unwanted) results. A bug of this nature was found in the SQLite interface for Python (PySQLite), which resulted in Python dumping core when deallocation of error message strings was attempted with free(). 3. [for developers] This port contains support for multiuser/multiprocess access to databases using the OS/2 file locking primitives. Because of architectural issues in the SQLite code, I am not completely happy with the database locking implementation as the locking policy doesn't allow use of OS/2's capability to wait for release of file locks, but rather implements its own timeout strategy. As a result, much more attention needs to be paid to handling locking issues in multiuser/multiprocess applications than I believe should be necessary - at least on OS/2 (and also Linux/*BSD). 4. [for developers] include/sqlite.h has been modified to include support for compilers that don't use the _System calling convention by default, such as VisualAge C++ and OpenWatcom - see the sqlite.h._System.patch file in the src subdirectory for the changes made from the standard sqlite.h. The files sqlite_va.exe and sqlite_ow.exe in the bin subdirectory were compiled with VisualAge C++ 3.65 and OpenWatcom 1.3 respectively, with only minor modifications required for compilation to succeed (though both the binaries lack readline support); the shell.c.VACPP.patch file in the src subdirectory contains the necessary changes. An important consideration highlighted in the shell.c patch is the necessity for declaring callback functions as using the _System calling convention, when using compilers other than EMX's gcc. I haven't yet attempted to use Innotek's gcc toolchain with this code. Support OS/2 specific issues, such as applications abnormally aborting or issues with building applications on OS/2 with this port, can be addressed to me at the email address below. Issues with SQL or other general behaviour should be directed, at least in the first instance, towards SQLite's author(s) - see the included documentation or the SQLite home page noted above for contact details. Note that SQLite's authors will not be able to help with OS/2 specific issues. Legal matters This software is provided 'as-is', without any express or implied warranty. In no event will the packager be held liable for any damages arising from the use of the software. The SQLite code has copyright disclaimed. I quote from the source file src/main.c: /* ** 2001 September 15 ** ** The author disclaims copyright to this source code. In place of ** a legal notice, here is a blessing: ** ** May you do good and not evil. ** May you find forgiveness for yourself and forgive others. ** May you share freely, never taking more than you give. ** ************************************************************************* ... Andrew MacIntyre email: andymac@bullseye.apana.org.au, or andymac@pcug.org.au web: http://www.andymac.org/ 25 March, 2005.

This is a binary installation package for the pysqlite extension module for Python, version 0.5.1, built for the OS/2+EMX port of Python 2.3.4. pysqlite is an interface to the SQLite embedded SQL database package, and includes a Python DB-API 2.0 compatible wrapper module. Please read README.pysqlite and LICENSE.pysqlite. With SQLite the entire database engine is implemented in a library, and SQLite based applications can be used in the same way the dBase and MS Access applications can be used, individually and across a network. There is no server process or system, as there is with PostgreSQL, MySQL, DB/2 etc. Please refer to the README.pysqlite file for more information about the pysqlite module. The source archive (pysqlite-0.5.1.tar.gz) this package is based on was found at http://pysqlite.sourceforge.net/. No source modifications were necessary. The only modification to the Distutils setup.py script was to add information about library names and locations. This module is requires SQLITE28.DLL, which is available separately from the Hobbes archive or my website (in the libraries section) in sqlite-2.8.*-os2.zip (* is 15 at time of writing). You must install this DLL before you can use this package. You need the Python 2.3, 2.3.2, 2.3.3 or 2.3.4 port installed before you can install this package - you should be able to get it where you obtained this archive. pysqlite depends on the eGenix mxBase package, for which a binary installation which should also be obtainable from the same source as this package. To install (assuming a working Python installation), change to the directory containing the install script (install.cmd), and execute the script. Please let me know if you encounter any problems with the installation package. Bug reports about pysqlite should be directed as specified on the pysqlite home page. This software is provided 'as-is', without any express or implied warranty. In no event will the packager be held liable for any damages arising from the use of the software. Andrew MacIntyre andymac@bullseye.apana.org.au http://www.andymac.org/ August 22, 2004.

SQLite 2.8.8 for OS/2 --------------------- This is a port of the SQLite embedded SQL database library, v2.8.8, to OS/2. Please see http://www.sqlite.org/ for more information about SQLite. Dependancies sqlite.exe requires the EMX runtime environment - v0.9d at least. Installation 1. copy sqlite.exe to a directory on the PATH. 2. copy sqlite28.dll to a directory on the LIBPATH, or make sure that you use BEGINLIBPATH or ENDLIBPATH appropriately. 3. if you intend compiling your own SQLite code, copy the contents of the include and lib subdirectories to locations appropriate for your development tools. Documentation The doc subdirectory contains the SQLite README, manpage (sqlite.1), and HTML documentation. Source The src subdirectory contains the Makefile, module definition file, and a patch file with the changes to the original source. YOU HAVE BEEN WARNED 1. While the build infrastructure requires the EMX 0.9d toolchain, the DLL (sqlite28.dll) has been built as a standalone DLL (-Zso -Zsys EMX gcc options) so is not dependant on the EMX runtime. In consequence, the library should be able to be used from any development environment that can call OS/2 DLL APIs, though the sqlite.h header in the include subdirectory does not contain any calling convention keywords which may be required by other compilers (_System or __syscall, etc). The library has been compiled with multithread support (-Zmt), and the sqlite API is fully multithreaded, with certain restrictions (see the SQLite documentation for more information). 2. As a consequence of the DLL being built as a standalone DLL, care must be taken about releasing memory allocated by SQLite calls. There are some SQLite API functions that allocate memory for which responsibility of deallocation is assigned to the caller. The sqlite_freemem() function is used for this purpose - free() should not be used for such memory, as your application's runtime memory allocator won't have any record of the memory and using free() will have undefined (and probably unwanted) results. A bug of this nature was found in the SQLite interface for Python (PySQLite), which resulted in Python dumping core when deallocation of error message strings was attempted with free(). 3. This port contains support for multiuser/multiprocess access to databases using the OS/2 file locking primitives. Because of architectural issues in the SQLite code, I am not completely happy with the database locking implementation as the locking policy doesn't allow use of OS/2's capability to wait for release of file locks, but rather implements its own timeout strategy. As a result, much more attention needs to be paid to handling locking issues in multiuser/multiprocess applications than I believe should be necessary - at least on OS/2 (and also Linux/*BSD). Support OS/2 specific issues, such as applications abnormally aborting or issues with building applications on OS/2 with this port, can be addressed to me at the email address below. Issues with SQL or other general behaviour should be directed, at least in the first instance, towards SQLite's author(s) - see the included documentation or the SQLite home page noted above for contact details. Note that SQLite's authors will not be able to help with OS/2 specific issues. Legal matters This software is provided 'as-is', without any express or implied warranty. In no event will the packager be held liable for any damages arising from the use of the software. The SQLite code has copyright disclaimed. I quote from the source file src/main.c: /* ** 2001 September 15 ** ** The author disclaims copyright to this source code. In place of ** a legal notice, here is a blessing: ** ** May you do good and not evil. ** May you find forgiveness for yourself and forgive others. ** May you share freely, never taking more than you give. ** ************************************************************************* ... Andrew MacIntyre email: andymac@bullseye.apana.org.au, or andymac@pcug.org.au web: http://www.andymac.org/ 26 December, 2003.