Character Set Supported by InterBase ToGo on Android
|Character Set||Char. set ID||Max. Char. Size||Min. Char Size|
|NONE||0||1 byte||1 byte|
|ASCII||2||1 byte||1 byte|
|OCTETS||1||1 byte||1 byte|
|UNICODE_FSS||3||3 bytes||1 byte|
|UTF_8/UTF8**||59||4 bytes||1 byte|
|UNICODE_BE/UCS2BE||8||2 bytes||2 bytes|
|UNICODE_LE/US2LE||64||2 bytes||2 bytes|
Licensing ToGo and IBLite for Android
RAD Studio Seattle users only get InterBase ToGo Test Deployment and IBLite licenses with their product. Both InterBase ToGo Test Deployment and IBLite can be used for development and testing.
When you are ready to deploy your applications to customers/production/appstore, you can either use the free IBLite license you have, or contact Embarcadero for an InterBase ToGo license.
InterBase Runtime File Locations for Android
The InterBase-related files are separated into two categories: Temporary files created by InterBase at run time, Read/Write files, and files used by InterBase for setup.
- Temporary files created by InterBase at run time:
- These files are created under the external storage location mentioned above, /data/data/<package_name>/files/interbase directory. interbase.log and other transient files such as isc_lock, isc_init and temporary sort files are also created there.
- Read/Write files and files used by InterBase for setup:
- These files are created under the external storage location mentioned above, /data/data/<package_name>/files/interbase directory. The following files should be delivered to this directory: ibconfig, interbase.msg, license/ folder and related license files, and, admin.ib (if used).
- For OTW/SSL connections, the recommended folder for providing supporting files is /data/data/<package_name>/files/interbase. In your OTW connection, please be sure to provide relative argument values. For example:
10.20.10.20?ssl? serverPublicFile=/data/data/<package_name>/files/interbase/ ibserverCAfile.pem??:<database_file_path>
Deploying InterBase with Your Applications on Android
The databases deployed on the mobile device can either have centralized user authentication via admin.ib, or, use EUA to control user access within the database. EUA use could limit the need to deploy admin.ib on the target mobile device for database access.