When developing applications with Xojo, choosing the right backend is crucial for managing data efficiently. Traditionally, Xojo developers rely on SQL databases such as SQLite, MySQL, or PostgreSQL for their desktop, web, and mobile applications. However, there is an alternative that provides a more flexible and modern approach to backend development: PocketBase.

PocketBase is an open-source backend perfect for your multi-platform Xojo application. It offers a simple-to-use API and a built-in admin panel to manage the data from any web browser. No other tool such as MySQL, Workbench, or SQL Studio is needed. In this post, I will explain how it compares to traditional SQL databases and demonstrate how to integrate it into a Xojo project.

Why Choose PocketBase for Your Xojo App Backend?

PocketBase is a lightweight, self-hosted backend designed for simplicity and flexibility. Unlike traditional SQL databases that require a separate backend service or API layer, PocketBase is an all-in-one solution that combines the database and API.

Key Features:

Embedded Database – Powered by SQLite, eliminating the need for a separate database server.

Built-in User Authentication – Supports email/password logins, OAuth2 sign-ups, and one-time password (OTP) with minimal setup.

File Storage – Store and retrieve files locally or via S3.

Cross-Platform Compatibility – Runs on macOS, Windows, and Linux. Can communicate via URLConnection making it ideal for Xojo’s desktop, web, and mobile platforms.

Easy Deployment – A single binary file that can be self-hosted or deployed anywhere with minimal configuration.

Setting Up PocketBase for a Xojo App

To get started, I have simplified some steps below. If you get stuck or want more in-depth instructions take a look at the documentation.

• Download PocketBase
  • Visit PocketBase and download the latest release for your operating system.
  • Extract the files to your project directory.
• Run PocketBase
  • Start the PocketBase server by navigating to the extracted folder in the command prompt/terminal.
  • Run the command: ./pocketbase serve to start the server.
• Access the Admin Panel
  • Open http://127.0.0.1:8090/_/ in a web browser and set up an admin account.
• Add a User
  • In the PocketBase admin panel, create a new record in the users collection. (Collections are the equivalent of a table in SQL.)

Connect Xojo to PocketBase

Now that your PocketBase server is running, integrate authentication into your Xojo desktop app. In this example, we will handle authentication in the open event of the main window. This will demonstrate how Xojo interacts with PocketBase’s authentication API.

Implement the Login Request

Add the following code to the open event of your main window:

Var userEmail As String = "email@email.com"
Var userPassword As String = "MyPassword!"
Var loginURL As String = "http://127.0.0.1:8090" + "/api/collections/users/auth-with-password"
Var conn As New URLConnection
conn.RequestHeader("Content-Type") = "application/json"
 
Var loginPayload As New JSONItem
loginPayload.Value("identity" ) = userEmail
loginPayload.Value("password") = userPassword
conn.SetRequestContent(loginPayload.ToString, "application/json")
 
Var loginResponse As String = conn.SendSync("POST", loginURL)
Var jsonResponse As New JSONItem(loginResponse)
Var userInfo As JSONItem = jsonResponse.Lookup("record", New JSONItem)
Var userID As String = userInfo.Lookup("id", "")
Var authToken As String = jsonResponse.Lookup("token", "")
 
If authToken.Length > 0 Then
  MessageBox("Login successful! Welcome, User ID: " + userID)
Else
  MessageBox("Login failed. Please check your credentials.")
End If

Update Your Credentials and URL

Replace userEmail and userPassword with the credentials you used to create a user in PocketBase. Also, ensure the loginURL matches your PocketBase instance (without /_/ at the end).

Run The App

Launch your Xojo app. If authentication is successful, a message box will display the user’s ID. Otherwise, you will see an error message indicating that the credentials are incorrect.

Wrapping Up

In this article, you have successfully set up a PocketBase server, created a record, and integrated authentication into your Xojo app. PocketBase simplifies backend development by handling authentication and data storage—all without the need for a traditional SQL database.

With PocketBase, there is no need to set up complex user tables, hash passwords, or build a custom API. Collections can be easily managed directly from the web via the admin panel. This means you can spend less time managing infrastructure and more time focusing on bringing your app to market.

To help you get started, I’ve created a collection of example projects, which you can find here:

Xojo-Pocketbase-Examples

If you’d like to discuss how Iron Elephant Solutions has used Xojo and PocketBase in real-world applications, feel free to reach out through our website or add me on LinkedIn.

Ezekiel Burke is the founder of Iron Elephant Solutions. He focuses on building custom, scalable, and affordable software that helps businesses work smarter. With 15+ years of experience, he specializes in full-stack development, process automation and systems integration, creating solutions that simplify complex workflows.

What is SOUNDEX?

SOUNDEX is a core function in SQLite that encodes a string into a 4-byte sequence, enabling indexing based on pronunciation. While the technical details of the algorithm are available on Wikipedia, the gist is that SOUNDEX(“Smith”) will match SOUNDEX(“Smythe”), making it useful for large searches to identify different spellings of the same term.

How is it used?

For the curious, you can see how words are indexed by simply invoking a select on a SOUNDEX term:

Var db As New SQLiteDatabase
db.Connect

Var rs As RowSet
rs = db.SelectSQL("SELECT SOUNDEX('Smith')")
Var smith As String = rs.ColumnAt(0).StringValue
rs = db.SelectSQL("SELECT SOUNDEX('Smythe')")
Var smythe As String = rs.ColumnAt(0).StringValue

Running this you’ll notice that ‘Smith’ and ‘Smythe’ both return the same SOUNDEX 4-byte sequence of “S530” — Here’s a quick breakdown of how this was generated:

1. First Letter (S): The first letter of the name stays the same, so “S” from the name “Smith” or “Smythe” becomes the first character in the code.
2. Numbers (530): The remaining characters in the code represent the sounds of the next letters in the name. Each number is based on a group of similar-sounding consonants:
   • 5 = “M” (because M sounds like “M” in “Smith” or “Smythe”)
   • 3 = “T” (because T sounds like “T” in “Smith” or “Smythe”)
   • 0 = No sound match or a vowel, so it acts as a filler to complete the 4-character code.

Practical Use Case

With a better understanding of the algorithm, we can put it to practical use by searching our database for names that sound similar to “Smith.”

db.ExecuteSQL("CREATE TABLE contacts(id INTEGER PRIMARY KEY, name TEXT)")
db.ExecuteSQL("INSERT INTO contacts (name) VALUES ('Smith'), ('Smythe'), ('Simith'), ('John')")

rs = db.SelectSQL("SELECT name FROM contacts WHERE SOUNDEX(name) = SOUNDEX('Smith')")

// Expected to find 3 names: Smith, Smythe, and Simith
Var namesFound As Integer = rs.RowCount

The Fuzzy Conclusion

Because the SOUNDEX algorithm is designed around English pronunciation patterns, it may not work as well for languages with different sound structures or alphabets, so results may vary depending on the language. It’s also worth noting that this feature is available for all targets, except Android at this time.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What’s New in Xojo 2024 Release 3

We’ve been working hard to bring you the best possible cross-platform development experience, and Xojo 2024 Release 3 delivers. Here are some of the highlights:

These updates and enhancements are designed to make your development experience more efficient, productive, and enjoyable. Whether you’re building a new application or updating an existing one, Xojo 2024 Release 3 provides you with the tools and capabilities you need to succeed.

Get Started

To learn more about Xojo 2024 Release 3 and to get started with the development process, please visit the Xojo 2024r3 Release Notes. The update can be downloaded right now, from the Xojo downloads page.

What’s Next?

We’re always working on new features, updates, and enhancements to our platform. If you have any suggestions or ideas, please don’t hesitate to add them to the Xojo tracker. We’re always looking for ways to improve and expand Xojo.

Thank you for being part of the Xojo community. We’re excited to see what you’ll create with Xojo 2024r3!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Why would you need a WebDataSource, isn’t AddRow enough?

If you are making a quick prototype, or for small data sets that won’t grow too much, yes, you can absolutely place a WebListBox into your WebPage and fill it using AddRow. If your WebListBox displays a fixed, small amount of data, say around 500~1000 rows, WebDataSource can be overkill.

However, for data that comes from a large database, it’s a different story. You could waste precious server resources duplicating the same data you have in your database into your app’s memory. And even worse, the data would be duplicated in every Session seeing that WebListBox.

In this tutorial, this is the WebListBox we are going to build:

Let’s prepare a million records database to play with.

In this example we will use a humble SQLite database, but keep in mind a WebDataSource can be anything. For example you could display the result of calling an external API, or your hard drive filesystem.

The following SQL creates a table called “things”, with three columns: “foo”, “bar” and “baz” with one million rows:

CREATE TABLE things (
  id    INTEGER PRIMARY KEY AUTOINCREMENT,
  foo TEXT,
  bar TEXT,
  baz TEXT
);

-- Time to populate that table
WITH RECURSIVE cnt(x) AS 
(
   SELECT
      1 
   UNION ALL
   SELECT
      x + 1 
   FROM
      cnt LIMIT 1000000
)
INSERT INTO things (foo, bar, baz)
SELECT
    'foo_' || x AS foo,
    'bar_' || x  AS bar,
    'baz_' || x AS baz
FROM cnt;

-- Finally, let's create some indexes, so we can sort the columns quickly
CREATE INDEX "idx_foo" ON things (
    foo, id, bar, baz
);

CREATE INDEX "idx_bar" ON things (
    bar, id, foo, baz
);

CREATE INDEX "idx_baz" ON things (
    baz, id, foo, bar
);

VACUUM;

We just need to store this SQL as a string constant, for convenience. Let’s create one, called kDatabaseSetupSQLite in your Application class, and paste it above the SQL code.

First Time Setup

The first time we launch the application, we need to make sure our database file has been created and populated. It won’t take too much to generate the database, but we’ll try to do it just once anyway.

Create a new method in your App class, called DBFile, that returns a FolderItem, pointing to the place we want to store the DataBase. Make it Public, as we will use this method later from the Session. The contents:

Return SpecialFolder.Desktop.Child("test-db.sqlite")

Nothing fancy. Use another path if you want. It will be around ~200MB, just remember to delete it when you don’t need it anymore.

Let’s create another App method, called SetupDatabase. It will be in charge of creating and populating the database just once, so if you restart the server, the data will still be there:

Var db As New SQLiteDatabase
db.DatabaseFile = DBFile
db.WriteAheadLogging = True

// The file is already there, no need to build it again
If db.DatabaseFile.Exists Then
  Return
End If

db.CreateDatabase
db.Connect
db.ExecuteSQL(kDatabaseSetupSQLite)

Lastly, implement the App.Opening event and add a method call to SetupDatabase:

SetupDatabase

That should do the trick.

Preparing the Session

It’s recommended to have a Database instance for each Session. Add a new public Property to your Session class called Database of type SQLiteDatabase.

Then, add a handler for the Opening event with the following code:

Database = New SQLiteDatabase
Database.DatabaseFile = App.DBFile
Database.WriteAheadLogging = True
Database.Connect

Every time a user arrives to the web application, a new isolated SQLiteDatabase connection will be created.

Implementing the WebDataSource Interface

Since Xojo 2024r2, the amount of methods you need in order to implement WebDataSource has been reduced.

Create a new class called DatabaseDataSource. Then, in the inspector panel, select the WebDataSource interface:

This includes the three required methods: ColumnData, RowCount and RowData.

ColumnData
In this method, you need to return an array of WebListBoxColumnData. We have four columns in this example, here is the code:

Var result() As WebListBoxColumnData
result.Add(New WebListBoxColumnData("ID", "id"))
result.Add(New WebListBoxColumnData("Foo", "foo"))
result.Add(New WebListBoxColumnData("Bar", "bar"))
result.Add(New WebListBoxColumnData("Baz", "baz"))

Return result

RowCount
Xojo needs to know the amount of data your data source has. Returning an Integer is enough, but we will query our database.

Try
  Var rows As RowSet = Session.Database.SelectSQL("SELECT COUNT(*) AS counter FROM things")
  Return rows.Column("counter").IntegerValue
Catch DatabaseException
  Return 0
End Try

RowData
This is the place where you need to return the row contents. As you can see, there is a rowCount and a rowOffset parameter, meaning that we won’t need to return 1 million records. The control just loads a subset. The amount is dynamically calculated, and varies depending on the height of your WebListBox and the height of the rows.

A sortColumns parameter is also provided. If you allow your users to sort the columns, you need to use it to know the column and direction. Fortunately, this example has sortable columns. Here is the code to comply with the WebDataSource Interface:

Var sql As String = "SELECT id, foo, bar, baz FROM things"
If sortColumns <> "" Then
  sql = sql + " ORDER BY " + sortColumns
End If
sql = sql + " LIMIT " + rowOffset.ToString + ", " + rowCount.ToString

Var result() As WebListBoxRowData
Var rows As RowSet = Session.Database.SelectSQL(sql)

// This isn't needed, it's just to demonstrate how to use cell renderers
Var style As New WebStyle
style.Bold = True
style.BackgroundColor = Color.Teal
style.ForegroundColor = Color.White

For Each row As DatabaseRow In rows
  Var newRowData As New WebListBoxRowData
  newRowData.PrimaryKey = row.Column("id").IntegerValue
  newRowData.Value("id") = row.Column("id")
  newRowData.Value("foo") = row.Column("foo")
  newRowData.Value("bar") = New WebListBoxStyleRenderer(style, row.Column("bar"))
  newRowData.Value("baz") = row.Column("baz")
  result.Add(newRowData)
Next

Return result

Preparing the User Interface

You’ve reached the easiest part, building the interface takes less than a minute.

1. Drop a DatabaseDataSource control into your WebPage
2. Drop a WebListBox control into your WebPage
3. In the WebListBox Opening event, configure the DataSource

If you name your DataSource instance “MyDataSource”, this is the line of code required in the WebListBox Opening event:

Me.DataSource = MyDataSource

Here is a short video:

That’s It!

The WebListBox control, when combined with a WebDataSource, is a very robust and performant solution for displaying a large set of data.

Download the project:

Happy coding!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Out With The Old

The old database connections were quite limiting, requiring you to create a new connection and re-enter all the parameters whenever one changed. With our new Database Connection items, you can now easily update specific connection parameters directly in the inspector.

Additionally, you can now choose whether the item will auto-connect or if you prefer to connect to it later in your code.

Connecting to a Specific Database

There are times when you need to connect to a database for debugging and testing, but for the final builds, you want to connect to your production database/server. Setting this up correctly with the old database connection method required creating two separate connection items—one for debug and one for release. With the new Database Connection items, this process is much simpler and fits more easily into the build process. You now have several new Database Connection subitems that can be customized based on the stage of your build. These subitems are linked to the Stage Code in your Shared Build Settings, ensuring that when you build a final release, your database connection uses the correct settings automatically.

Additional Database Features

In addition to this change, there are two new database APIs that may be useful to you:

1. A new method, IsConnected, has been added to the SQLiteDatabase, ODBCDatabase, PostgreSQLDatabase, and MySQLCommunityServer classes. This method returns true if the connection is still active, and false if it is not.
2. We’ve enhanced Database.AddRow with a new signature that returns the unique ID of the newly inserted row. This feature is supported for SQLiteDatabase, ODBCDatabase, PostgreSQLDatabase, and MySQLCommunityServer classes. It is recommended to use this new API instead of the deprecated SQLiteDatabase.LastRowID and MySQLCommunityServer.LastInsertedRowID

Let’s explore how the new Database.AddRow feature can assist you. Previously, only SQLiteDatabase and MySQLCommunityServer had APIs to retrieve the unique ID of the last inserted row. Now, PostgreSQLDatabase and ODBCDatabase also have this capability by using the new Database.AddRow(tableName As String, row As DatabaseRow, idColumnName As String = "") As Integer

The new aspect of this signature is the idColumnName parameter and the return value. For databases that support the SQL RETURNING clause, the idColumnName specifies the column whose value will be returned. For databases that do not support the RETURNING clause, we will use the suitable method for each specific database to return a unique value.

We recognize the significance of databases in your Xojo apps. So with these updates to database connectivity for your desktop, web and console apps, and the addition of new features, we aim to make your database programming easier and more efficient.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

What are Transactions?

A transaction is a sequence of SQL commands executed as a single unit, adhering to the ACID properties:

• Atomicity: All or none of the changes are applied.
• Consistency: The database remains in a valid state.
• Isolation: Concurrent transactions do not interfere with each other.
• Durability: Once committed, changes are permanent.

Basic Transaction Commands

SQLite supports three main commands for transactions:

• BEGIN TRANSACTION: Starts a new transaction.
• COMMIT: Finalizes changes and makes them permanent.
• ROLLBACK: Reverts changes made since the last BEGIN TRANSACTION.

Sample in Xojo

Let’s consider a banking application where money is transferred between accounts. Without transactions, inconsistencies might occur. For example, if the first update (deducting money from one account) succeeds but the second update (adding money to another account) fails, the database will be left in an inconsistent state, reflecting a transfer that didn’t fully happen. Using transactions ensures that both updates either succeed or fail together, maintaining consistency.

Var db As New SQLiteDatabase
db.DatabaseFile = FolderItem.ShowOpenFileDialog("bank.db")
If db.Connect Then
  Try
    db.BeginTransaction
    db.ExecuteSQL("UPDATE accounts SET balance=balance-100 WHERE account_number=123")
    db.ExecuteSQL("UPDATE accounts SET balance=balance+100 WHERE account_number=456")
    db.CommitTransaction
  Catch e As DatabaseException
    db.RollbackTransaction
    MessageBox("Transaction failed: " + e.Message)
  End Try
Else
  MessageBox("Failed to connect to the database")
End If

In this example, BeginTransaction starts the transaction. The UPDATE commands perform the transfer. If successful, CommitTransaction finalizes the changes. If an error occurs, RollbackTransaction reverts all changes.

Advanced Transaction Control

SQLite also offers advanced transaction modes: DEFERRED, IMMEDIATE, and EXCLUSIVE.

• DEFERRED: Default mode, acquires a write lock only when the first write operation occurs.
• IMMEDIATE: Acquires a write lock immediately upon transaction start.
• EXCLUSIVE: Prevents all other read and write operations during the transaction.

Choosing the transaction type depends on the application’s specific requirements. DEFERRED balances concurrency and consistency, while IMMEDIATE and EXCLUSIVE provide higher isolation at the cost of concurrency.

Example of Advanced Transaction

If db.Connect Then
  Try
    db.ExecuteSQL("BEGIN IMMEDIATE TRANSACTION")

    ' Perform read and write operations here

    db.CommitTransaction
  Catch e As DatabaseException
    db.RollbackTransaction
    MessageBox("Transaction failed: " + e.Message)
  End Try
Else
  MessageBox("Failed to connect to the database")
End If

In this example, an IMMEDIATE transaction ensures exclusive access from the start.

Transaction Speed Considerations

The speed of transactions in SQLite can be influenced by various factors:

• Batching Operations: Grouping multiple operations in a single transaction can significantly improve performance.
• Disk I/O: The underlying storage medium and its I/O performance impact transaction speed.
• Transaction Type: IMMEDIATE and EXCLUSIVE transactions might be slower due to locking mechanisms but provide higher isolation.

Batching multiple operations into a single transaction reduces the overhead of repeatedly acquiring and releasing locks, leading to faster execution.

Benefits of Using Transactions

Using transactions offers numerous benefits:

1. Atomicity: Prevents the database from being left in an inconsistent state due to partial updates.
2. Consistency: Ensures the integrity of the database by transitioning only to valid states.
3. Isolation: Prevents interference between concurrent transactions.
4. Durability: Ensures that committed changes are permanent, even in the event of a system failure.

By understanding and applying transactions, developers can create robust applications that handle data modifications seamlessly, minimizing the risk of errors and inconsistencies.

Based on the Ducklet Blog article. Happy coding!

Martin T. is a Xojo MVP and has been very involved in testing Android support.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

This paper probably explains the biggest issue regarding SQL that persists to this day: its pronunciation.

I always flip between saying “sequel” and “ess cue ell” depending on context. The authors used SEQUEL as an acronym of Structured English QUEry Language. Over time this was referred to as Structured Query Language and the initialism of SQL took hold. Still, the pronunciation of sequel seems to have also stuck. Anyway, pronounce it how you want — I won’t judge.

I’ve sometimes seen people claim that SQL stands for Standard Query Language. As the above clearly shows, that is not true. And if you’ve used SQL at all with more than one database, you also have empirical evidence that there is not much standard about it beyond the main keywords.

The paper itself is only about 15 pages, so not long at all. I found this surprising as I expected it to be some lengthy and detailed specification written for academics.

But it’s not.

It starts by talking about the relational model of data, a somewhat new concept at the time (first described in 1969), and the predicate calculus, introducing a sublanguage called SQUARE, which strikes me a somewhat functional way of querying relational data. Math nerds do love their functional languages.

The authors then go on to introduce SEQUEL as a substitute for SQUARE and it’s here where we see the first syntax that you might recognize:

SELECT NAME
FROM   EMP
WHERE  DEPT = ’TOY’

Boolean expressions in the WHERE clause are also covered along with functions in the SELECT clause. These are all things still being used to this day.

The main justification the authors use for SEQUEL is that the concepts of predicate calculus and SQUARE require “too much sophistication for the ordinary user”. I won’t argue with that!

They drive that point home by showing how to get data results using some example queries, first by using SQUARE and then comparing to the SEQUEL equivalents. Their first query is this:

Find the names of managers who manage more than ten employees.

Note that for this example, there is a previously defined database with one of the tables as follows:

EMP (NAME, DEPT, MGR, SAL, COMM)

The SQUARE example looks like this:

I’m not going to even try to explain this. Read the paper if you’re curious.

Here’s the SEQUEL version:

SELECT   MGR
FROM     EMP
GROUP BY MGR
WHERE    COUNT (NAME) > 10

Well, now. That certainly makes more sense to me. I’ll bet that everyone reading this knows exactly how to parse out the SEQUEL command. It would actually work as-is in a database such as SQLite today!

There are other examples in the paper as well. Like I said, it’s somewhat short so you might find it to be an interesting read.

Happy 50th Birthday, SEQUEL (SQL)!!

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

Functions

There are a few new SQLite functions that can now be used in your SQL statements.

concat()

The concat() function takes an arbitrary number of string parameters and concatenates them all together. Previous versions of SQLite required you to instead use the concat operator, this is the double-pipe: ||. Concat() is a standard function on many other databases (PostgreSQL, MySQL and SQL Server) so it is nice to finally see it available on SQLite as it allow more consistent SQL code.

Using the Chinook sample database, this SQL concatenates the Name and Composer columns from the Track table:

SELECT concat(Name, ‘ by ‘, Composer) FROM Track

Here is the output:

concat_ws()

The concat_ws() method is concat but with a separator. Strange naming aside, it works the same except that the first parameter is used a separator that is inserted between each string. This SQL separates the Name, Composer and Milliseconds with “—“:

SELECT concat_ws(‘---‘, Name, Composer, Milliseconds) FROM Track

Here is the output:

timediff()

The timediff() function calculates the elapsed time between two dates and returns the result in a human-readable format.

This SQL displays the time difference between Dec 12, 2023 and March 26, 2024:

SELECT timediff('2023-12-12','2024-03-26')

Here is the output of 3 months and 14 days (note that it is negative because the earlier date is first in the parameter list):

Other Changes

Overall I didn’t notice many other other significant new features. However, many bugs have been fixed, especially around database integrity checks and the somewhat new JSON support.

You can find the full list of SQLite changes on their Release History page.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

Xojo Cloud is optimized for Xojo applications. It is specifically designed to provide the best possible performance and stability for Xojo web applications. We optimize Xojo Cloud for performance, so your web apps will run smoothly and seamlessly. You can even monitor server stats from within the Xojo IDE.

Xojo Cloud is focused on simplicity and ease of use and requires zero configuration. Designed with the Xojo developer in mind, Xojo Cloud’s Control Panel makes it easy to deploy and manage web applications. Purchase a server, open a web project in Xojo and click Deploy to upload and install to Xojo Cloud. Not just for web apps, Xojo Cloud includes Apple Push Notification server (APNs) support for your iOS apps. Set up SSL, PostrgeSQL, MySQL, SFTP and a SSH Tunnel with a click in the Xojo Cloud Control Panel (the Control Panel itself is a Xojo web app). The administration of a web server is a significant and constant task; Xojo Cloud allows you to leave that behind and focus on your projects.

We take security very seriously. Xojo Cloud offers advanced security features to protect your data from cyberthreats, including a smart firewall, intrusion and hacking detection and Security-Enhanced Linux. Unlike most hosting solutions that provide little to no security, each Xojo Cloud server is built with our state-of-the-art, industrial-strength, multi-tiered security system woven into its very core. 

Additional features and benefits include daily automatic backups, load balancing and support from the Xojo team. With nine global hosting locations, you are able to host your Xojo web applications close to your users, for speed and an ideal overall experience.

In addition to the standard options, Xojo Cloud servers with more RAM, storage and Virtual CPUs are available. Contact customer support for details about personalized plans. 

Whether you are a seasoned Xojo developer or just getting started, Xojo Cloud provides an intuitive and user-friendly hosting solution for Xojo web applications. Today is a good day to start using Xojo Cloud, visit our website to learn more or see the Xojo Store to pick your package and location.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Database Support

Xojo works with a wide variety of databases. SQLite is bundled with your Xojo license and is a great beginner database for desktop, web and mobile apps. Xojo includes direct support for SQLite, PostgreSQL and MySQL. Plus, you can use ODBC to connect to just about anything else, such as Oracle, MS-SQL Server, Microsoft Access, Firebird or even IBM iSeries.

Examples

To help you get started, there are many examples in the Examples/Databases folder included with the Xojo Download, including examples that connect to each of the supported databases. You can find a breakdown of the examples included in the Examples folder in the Xojo Programming Language Documentation.

Additionally, you can check out the Eddie’s Electronics sample app (located in Examples/Sample Applications/EddiesElectronics) to see how to share database code between Xojo desktop and Xojo web apps.

DBKit is an example project designed to make it easier to build desktop and web applications that are front-ends to databases. Specifically, DBKit makes it easy to connect a database table to the user interface controls on a layout. DBKit also handles a lot of the interface for you. You can read more about DBKit in the Xojo Documentation.

Read: Documentation

After you have reviewed the examples, the Database Overview in the Xojo Documentation will help with next steps. Remember, Xojo comes bundled with SQLite which is an excellent database for desktop, web and mobile apps. Read more about using SQLite in the Xojo Documentation and check out this SQLite Tutorial for more detail.

Watch: Videos

The Xojo YouTube channel has hundreds of videos on all things Xojo. Here are the most recent Xojo Database videos and playlists:

• Video: Connecting to a Database from Xojo
• Video: Updating a Database from Xojo
• Video: Querying a Database from Xojo
• Video: Managing the UI when Updating a Database
• Video: Using DBKit to easily connect databases to Xojo applications
• Playlist: Using Databases with Xojo – A growing, catch-all playlist for videos related to Xojo and databases.
• Playlist: Xojo and SQLite – SQLite comes bundled with Xojo and is a great database for beginners building desktop, web and mobile apps with Xojo.

Vendor Documentation

Lastly, you should always refer to the vendor-specific documentation for the database you are using to learn the specifics about how that database works, including SQL syntax.

• SQLite
• PostgreSQL
• MySQL
• Oracle Database
• Microsoft SQL Server

Xojo simplifies the development process, reduces complexity and empowers developers to create efficient and functional database applications with relative ease. The Xojo IDE is free to use for development and testing – design, develop, run and debug your app all without a license. Purchase a license when you are ready to compile your apps, licenses start at $149. Visit the Xojo Store to find the license right for your project.

If you have questions after you have reviewed these materials, the Xojo Forum is an accessible and essential resource for Xojo users of all levels. You can also contact Xojo directly with your questions.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

• STRICT tables
• PRAGMA table_list
• RIGHT and FULL OUTER JOIN
• Built-in JSON support

More about each of these below.

STRICT Tables

One of SQLite’s most unusual capabilities is that it does not care about what data goes into a column. Although you could specify a type for a column, it was really more of a suggestion as other types of data could be put into the column. This behavior is different than most other relational databases and can sometimes be a source of confusion.

Now you can create your tables using the STRICT keyword to force them to require column types and to force the column types to always be checked when putting data into them.

You are still limited to INT, INTEGER, REAL, TEXT and BLOB. That means there is still no DATE or DATETIME type like you might find in other databases. Instead use TEXT with YYYY-MM-DD format.

However, an ANY type was added which essentially allows you to clearly state that the column can contain anything. This allows you to have a mixture of specific types and generic types in your STRICT tables.

Note that the STRICT keyword goes at the end of the CREATE TABLE command:

CREATE TABLE Team (ID INTEGER, Name TEXT, Coach TEXT, City TEXT, PRIMARY KEY(ID)) STRICT;

The SQLite docs have more information about the new STRICT table feature.

PRAGMA table_list

With Xojo you could always get the list of tables by using the Database.Tables() method. However if you wanted to get the list of table using SQL you had to directly query the sqlite_master table.

Now there is a simple PRAGMA that can do the same thing:

PRAGMA table_list

It returns a list of tables and some other details about the table (which may change over time according to the SQLite docs).

RIGHT and FULL OUTER JOIN

Joining tables is a common task with SQL. The most common type of join is an INNER JOIN where only the rows common to both tables are included in the result. Other less common types of joins include LEFT OUTER, RIGHT OUTER and FULL OUTER (sometimes OUTER is omitted when referring to these types of joins).

SQLite has had support for LEFT OUTER joins for a long time, but support for RIGHT OUTER and FULL OUTER were missing. But now they are here, giving your more complicated queries better compatibly with the “big name” databases.

Learn more about these types of joins at W3 schools.

JSON Support

I’ve saved the big one for last: your SQL databases can now work with JSON data within columns.

Here is a sample table to work with with some JSON data that is stored in the players column:

CREATE TABLE team(id INTEGER PRIMARY KEY, Name TEXT, players TEXT);

INSERT INTO TEAM VALUES (NULL, 'Seagulls', '[ {"Name":"Bob","position":"1B"}, {"Name":"Tom","position":"2B"} ]')

INSERT INTO TEAM VALUES (NULL, 'Pigeons', '[ {"Name":"Bill","position":"1B"}, {"Name":"Tim","position":"2B"} ]')

INSERT INTO TEAM VALUES (NULL, 'Crows', '[ {"Name":"Betty","position":"1B"}, {"Name":"Tina","position":"2B"} ]')

Let’s say you want to get the first player on each team. Without SQLite JSON support you would have to pull out the JSON column data and parse it out separately. But now you can do it with this SQL like this:

SELECT players -> 0 FROM team

The above SQL says: for each row fetch the first array element from the JSON data in players.

This is how you would list all the players on all the teams:

SELECT team.Name, json_each.value -> 'Name' FROM team, json_each(team.players)

And if you want to get the actual value without the quotes, you can use the ->> operator (and also rename the result):

SELECT team.Name, json_each.value ->> 'Name' As PlayerName FROM team, json_each(team.players)

The SQLite JSON support can do much, much more which you can read about on the SQLite JSON doc page.

Paul learned to program in BASIC at age 13 and has programmed in more languages than he remembers, with Xojo being an obvious favorite. When not working on Xojo, you can find him talking about retrocomputing at Goto 10 and on Mastodon @lefebvre@hachyderm.io.

• RETURNING on DELETE, INSERT and UPDATE commands
• ALTER TABLE DROP COLUMN
• EXPLAIN QUERY PLAN

RETURNING Clause

The RETURNING clause can be used on DELETE, INSERT and UPDATE commands to get a value back after the command has run without having to do a separate query.

For example, you could send an UPDATE command that recalculates a value and have it return the new value like this:

UPDATE sales SET amount = amount * 2 WHERE ID = 1 RETURNING amount

This would now return the newly calculated amount, where as you would previously have to issue a separate SELECT statement to get the amount.

This example would append ” the Great” to the end of all names in the Artist table and return the new name along with the ID:

UPDATE Artist SET Name = Name || + " the Great" RETURNING Name, ArtistId

To access the RETURNING value from Xojo, you’ll want to send the command using SelectSQL instead of ExecuteSQL so that you can use a RowSet to get the values.

DROP Column

SQLite has historically been pretty inflexible when it comes to modify a table’s structure after it has been created. Until recently you could only rename a table and add new columns to it. Back in SQLite 3.25, the ability to rename existing columns on a table was added. And now you can also remove (drop) columns from a table.

You can do this using the standard syntax like this:

ALTER TABLE MyTable DROP COLUMN OldColumn;

Query Plan

A query plan describes how SQLite processes your SQL query. It is really only useful for debugging purposes. If you have a slow-running query it can sometimes be useful to look at the query plan to see if it is pointing out an obvious problem with the query, which might be that the query is doing a table scan rather than using an index.

To see a query plan, you put EXPLAIN QUERY PLAN in front of the SQL query. This features has been in SQLite for a long time, but it has recently gotten some output improvements that might make it easier to use. Be sure to give it a try.

As an example, here is how to get the query plan for a simple query using the AlbumArtist view in the Chinook database:

EXPLAIN QUERY PLAN SELECT * FROM AlbumArtist

The query plan looks like this, with separate rows returned for each evaluation:

To learn more about using SQLite with Xojo, check out these additional resources: Xojo SQLite Database Documentation, Tutorial: SQLite Basics, Blog Post: 3 Steps to Seamlessly Deploy SQLite Projects on Desktop, Web & iOS and Blog Post: Backwards SQLite Backups.

1. Adding the Database File

You probably created your SQLite database file using an external editor; so first add that file to your Xojo project. You can do that in several ways, but usually it’s best to add a Build Step. This way, the file will be automatically added to the folder every time you compile your app. Bonus: Doing this allows you to decide to use different paths when debugging or deploying your app.

Adding a Build Step in Xojo is the same for Desktop and Web projects. Select the target in the Build Settings then from the contextual menu choose the “Add to Build Settings > Build Step > Copy Files” option.

This gives you access to the Inspector Panel for the just-added item where you can enter a name for the Build Step, choose if the copy file action will be executed both for debugging or deployment and, most importantly, choose the location where the file should be copied when the app compiles.

The Destination menu contains a number of typical paths (or most relevant folders). For example, a good destination option would be “Resources Folder”. Don’t forget to add the database file itself using the buttons on the Build Editor toolbar.

On iOS, adding a Build Step is nearly the same as for Desktop and Web. The only difference is that you have to choose the icon with an iPhone picture in it in order to access the Build Step contextual menu> In addition to that, every added resource needs to be signed with a certificate.

2. Copying the Database File to a “Working” Folder

You may think that adding a Build Step is all you need to do, because if the database file is already copied to a well known path then you only need to provide that path as the DatabaseFile property on a new SQLiteDatabase instance. But this is not the case.

They are many reasons you shouldn’t do that, notably because the database would be open in read/write mode and if you write to that database file inside an application bundle, then you’d be modifying a resource and that would invalidate any certificate signature on your app.

The best thing to do is to check every time you run the app to see if the database file has already been copied from the app bundle (or folder) into a target folder that doesn’t have an access problem when it is time to use the database. The Application Support folder is a good place for Desktop apps, while the Documents folder is fine for Web and iOS apps.

For example, if our database file is named “EddiesElectronics.sqlite” and our app name is “Xojotest”, then we can add the following code fragment into the Opening Event Handler of a Desktop app. Also, make sure to add the pDatabase property to the App object in the Navigator:

Var source As FolderItem = SpecialFolder.Resource("EddiesElectronics.sqlite")
Var name As String = app.ExecutableFile.name.NthField(".", 1)

// Check if there is a folder with the App name in special Application Data
// if not, create it and copy the database file from Resources bundle/directory
If Not (SpecialFolder.ApplicationData.Child(name).Exists And SpecialFolder.ApplicationData.Child(name).IsFolder) Then SpecialFolder.ApplicationData.Child(name).CreateFolder

If Not SpecialFolder.ApplicationData.child(name).child(source.name).exists Then source.CopyTo(SpecialFolder.ApplicationData.Child(name))

Try
  // Create a SQLiteDatabase instance and try to open our database file from
  // the path
  pDatabase = New SQLiteDatabase
  pDatabase.DatabaseFile = SpecialFolder.ApplicationData.Child(name).Child("EddiesElectronics.sqlite")
  pDatabase.Connect

Catch e As DatabaseException
  MessageBox(e.Message)
End Try

For an iOS app, the code would be:

Var source As FolderItem = SpecialFolder.Resource("EddiesElectronics.sqlite")
// Check if our database file already copied on the Documents Sandbox folder
// if not, copy the database file from Resources bundle/directory

If Not SpecialFolder.Documents.Child("EddiesElectronics.sqlite").Exists Then
  source.CopyTo(SpecialFolder.documents)
End If

Try
  // Create a SQLiteDatabase instance and try to open database file from
  // the path
  pDatabase = New SQLiteDatabase
  Var f As FolderItem = SpecialFolder.Documents
  pDatabase.DatabaseFile = f.Child("EddiesElectronics.sqlite")
  Call pDatabase.Connect
  
Catch e As RuntimeException
  MessageBox(e.Message)
End Try

If you’re working on Xojo Cloud, the code is even shorter. First, make sure that the Copy File Build Step has the following values in the Inspector Panel:

• Destination: Contents Folder
• Subdirectory: Documents

Then, the code will be:

Try
  pDatabase = New SQLiteDatabase
  pDatabase.DatabaseFile = SpecialFolder.Documents.Child("EddiesElectronics.sqlite")
  pDatabase.Connect
Catch e As RuntimeException
  MessageBox(e.Message)
End Try

What about a Web app that you host? That would mean you are in control of the folder/directory you want to use to store the app resources. Thus, it wouldn’t make much sense to automate this process (but it is certainly doable following the same principles).

3. Simplifying the Process

What we have just done works, but it means you need to change the database file name, probably for every app you build. It also means that you’ll be writing the same code snippet again and again in every new app. Wouldn’t it be great to be able to extend the SQLiteDatabase in order to simplify that?

Well, let’s do that! Start by adding a new Module to the example project (for example, one named “DatabaseExtensions”) with a couple of methods on it. The first method will be the one executed on our Desktop, Web and Console apps, because all of these targets use the SQLiteDatabase class.

Add a new method using the following signature in the just-created Module:

OpenDatabase(databaseName As String)

It extends the SQLiteDatabase class, adding a new method that takes as parameter the name of the file we want to copy on the “work” folder/directory.

The code you should type on this method is:

pDatabase = New SQLiteDatabase

#If TargetDesktop Or TargetConsole Or TargetWeb Then

  Var source As FolderItem = SpecialFolder.Resource(databaseName)
  Var name As String = app.ExecutableFile.name.NthField(".", 1)
  // Check if there is a folder with the App name in special Application Data
  // if not, create it and copy the database file from Resources bundle/directory
  If Not (SpecialFolder.ApplicationData.Child(name).Exists And SpecialFolder.ApplicationData.Child(name).IsFolder) Then
SpecialFolder.ApplicationData.Child(name).CreateFolder
If Not SpecialFolder.ApplicationData.Child(nam).Child(Source.name).Exists Then source.CopyTo(SpecialFolder.ApplicationData.Child(name))

  Try
    // Create a SQLiteDatabase instance and try to open database file from
    // the path
    pDatabase.DatabaseFile = SpecialFolder.ApplicationData.Child(name).Child(databaseName)
    pDatabase.Connect

  Catch e As DatabaseException
    MessageBox(e.Message)
  End Try

#ElseIf TargetXojoCloud
  Try
    pDatabase.DatabaseFile = SpecialFolder.Documents.Child(databaseName)
    pDatabase.Connect
  Catch e As RuntimeException
    MessageBox(e.Message)
  End Try
#EndIf

Of course, we need to add the “pDatabase” property to our Module too: pDatabase As SQLiteDatabase

Now, you’ll only need to use:

OpenDatabase("EddiesElectronics.sqlite")

With the method selected in the Project Browser, click on the Attributes section of the Inspector Panel (the Cog Wheel icon), and uncheck the “iOS 64” checkbox. This way, that method will not be included when compiling for iOS apps.

The second method is the one we will be using for iOS apps. The method signature would be:

OpenDatabase(databaseName As String)

Type the following fragment of code in the associated Code Editor:

pDatabase = New SQLiteDatabase

Var source As FolderItem = SpecialFolder.Resource(databaseName)

// Check if the database file is already copied on the Documents Sandbox folder
// if not, copy the database file from Resources bundle/directory

If Not SpecialFolder.Documents.Child(databaseName).Exists Then
  source.CopyTo(SpecialFolder.Documents)
End If

Try
  // Create a SQLiteDatabase instance and try to open database file from
  // the path
  
  Var f As FolderItem = SpecialFolder.Documents 
  pDatabase.DatabaseFile = f.Child(databaseName)
  pDatabase.Connect
  
Catch e As RuntimeException
  MessageBox(e.Message)
End Try

Lastly, and with the method item still selected in the Navigator, go to the Attributes section of the Inspector Panel and make sure that the “iOS 64” checkbox is the only one selected under the “Include In” section. This way, we make sure that the method will be compiled only on iOS targets.

To Summarize

The use of Modules in combination with OOP Class Extension is a good way to get more flexibility when developing your apps, no matter if you are working on Desktop, Web or iOS. And that leads to convenient reutilization of code and less code to maintain through all your projects!

(You can find this article in Spanish here)

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

First, the performance of WAL mode (write-ahead logging) is improved when there are lots of connections all accessing the same database file. This ought to provide noticeable improvements for web apps that use SQLite databases.

If you use full text searching with FTS5, you can now enable trigram indexing to allow search terms to better match within text blocks.

A minor change is that the “substr()” SQL function can now also be called “substring()” for compatibility with SQL Server.

There are a few other performance improvements as well. Visit the SQLite site to read the official release notes.

Find more SQLite tips

memoryDB.Backup(fileDB, Nil, -1) 

Something that’s often overlooked is that you can use the Backup method to go the other way… that is, it can be used to load a disk-based database back into memory by simply swapping the parameters:

// Connect to the database file on disk
Var fileDB as New SQLiteDatabase
fileDB.DatabaseFile = SpecialFolder.Resources.Child("template.db")
fileDB.Connect

// Create the database in memory
Var memoryDB as New SQLiteDatabase
memoryDB.Connect

// "Backup" the file database into memory
fileDB.Backup(memoryDB, Nil, -1)

// Close the file database
fileDB.Close

And voila! You’ve restored the database back into memory!

For more information about this command, please see SQLiteDatabase.Backup on https://documentation.xojo.com.

If you aren’t already familiar with Xojo Cloud, it’s simple, secure, maintenance-free hosting for your Xojo web apps. 

SQLite Database Tip

For the first tip, which involves SQLite databases, this is the scenario: Let’s say you added a SQLite database to the project using a Build step and set the proper Folder/Subfolder, and then you connect to it from the Session.Opening event (or any other, for this case) in order to access its tables.

Even if you are running your Web app in local or debug mode (from the IDE) the connection to the SQLite database works, no matter if you’re typing the database file name in either upper or lowercase. Remember, when you are deploying the database to Xojo Cloud, you need to pass along the database name using the proper lowercase and uppercase characters in its original name.

Let’s suposse that the original database name on disk is “MyPrettyDatabase.sqlite”, then you’re using the following code in order to connect to it:

#if DebugBuild then
    f=SpecialFolder.Desktop.Child("myprettydatabase.sqlite")
#else
    f=specialfolder.documents.child("myprettydatabase.sqlite")
#EndIf

BBDD.DatabaseFile=f

Try

    BBDD.Connect

catch e as IODatabaseException

End Try

In this case, when running the web app from your computer everything will work fine (because most desktop operating systems use a case-insensitive file system, although Linux is often case-sensitive); but if you deploy the web app to Xojo Cloud you’ll find yourself with a database that does not connect. Fixing this is as simple as typing the string representing the database filename observing the uppercase characters existing in its original name:

#if DebugBuild then
    f=SpecialFolder.Desktop.Child("myprettydatabase.sqlite")
#else
    f=specialfolder.documents.child("MyPrettyDatabase.sqlite")
#EndIf

    BBDD.DatabaseFile=f

Try

    BBDD.Connect

catch e as DatabaseException

End Try

SQLite Tip: Xojo 2020r1 updated to SQLite 3.31.1, which adds some cool new features!

MySQL/MariaDB Database Tip

The second problem we’re solving involves the connection with MySQL/MariaDB databases hosted on a remote server from your Xojo Cloud app.

Although connecting to a remote MySQL database is well documented here, let’s review. If you need to establish this kind of connection, remember to open the Xojo Cloud firewall port first.

For example, something like this code snippet will let the web app work when deployed on Xojo Cloud and when you are doing a local test running it from the IDE (debug mode):

#If TargetXojoCloud
    Var fwp As New XojoCloud.FirewallPort(3306, XojoCloud.FirewallPort.Direction.Outgoing)
    fwp.Open
    If fwp.isOpen Then
        connectDatabase
    End If
#Else
    ConnectDatabase
#EndIf

Where, in this case, ConnectDatabase is the method in charge of doing the real connection setting the usual parameters agains the MySQLCommunityServer instance.

Order Your Nulls

You can now control where NULL values appear in columns when you use ORDER BY. Normally NULLs appear first in ascending sorts and last in descending sorts. But you can reverse that by using the NULLS FIRST or NULLS LAST syntax like this:

SELECT Name FROM Team ORDER BY Team NULLS LAST

PRAGMA Lists

There are three new PRAGMA commands that return various meta data about SQLite:

• PRAGMA function_list
• PRAGMA module_list
• PRAGMA pragma_list

You won’t really use this in your code, but they can be useful as a sort of help in your database tool to show you what’s available. I think PRAGMA function_list will be the most useful one.

Generated (Computed) Columns

I’ve saved the best for last. You can now Add columns to your tables whose values are calculated from other column values using standard operators and built-in SQLite functions (see the function_list above).

SQLite calls these “generated columns”, but “computed columns” or “calculated columns” are other terms for them.

These columns can be either Virtual or Stored. A Virtual Generated Column is calculated each time it is accessed so it can be slower, especially if the calculation is complex. A Stored Virtual Column is calculated when the row is added or updated and saved in the database. This means it will take up space in the database file, but will return its result faster.

To create one of these columns you use the GENERATED command after the type followed by the calculation after the AS and ended with either VIRTUAL or STORED. For example:

CREATE TABLE Product (
  ID INTEGER PRIMARY KEY,
  Price REAL,
  Quantity INT,
  Total INT GENERATED AS (Price*Quantity) VIRTUAL
)

You can INSERT some data into this table:

INSERT INTO Product (Price, Quantity) VALUES (5.00, 2)

Now you can query the table and ask for the Total column:

SELECT Total FROM Product

The result returns 10.

These type of columns are common in more powerful databases and it is great to see them in SQLite. Learn more about Generated Columns at the official SQLite doc page: https://sqlite.org/gencol.html

1. Adding the database file

You probably created your SQLite database file using an external editor; so first add that file to your Xojo project.

You can do that in several ways, but usually it’s best to add a Build Step. This way, the file will be added automatically to the folder of your choice every time you compile your app. Bonus: Doing this allows you to decide to use different paths when debugging or deploying your app.

In order to add a new Build Step in a Desktop project select the target in the Build Settings then, from the contextual menu, choose the “Add to Build Settings > Build Step > Copy Files” option.

The previous action will give you access to the Inspector Panel for the just-added item where you will be able to type a name for the Build Step, choose if the copy file action will be executed both for debugging or deployment and, most importantly, choose the location where the file should be copied when the app compiles.

In fact, the Destination menu contains a number of typical paths (or most relevant folders). For example, a good Destination option would be “Resources Folder”. Of course, don’t forget to add the database file itself using the buttons on the Build Editor toolbar.

When you’re working with a Web project, you’ll find exactly the same behavior, even if you choose to deploy with Xojo Cloud.

On iOS, the only change is that you’ll have to choose the icon with an iPhone picture in it in order to access the Build Step contextual menu; in addition to the fact that every added resource needs to be signed with a certificate.

2. Copying the database file to a “Working” folder

You may think that the previous step is all you need to do, because if the database file is already copied in a well know path then you only need to provide that path as the DatabaseFile property on a new SQLiteDatabase or iOSSQLiteDatabase instance. But this is not the case.

They are many reasons you shouldn’t do that, specifically because the database would be open in read/write mode and if you write to that database file inside an application bundle, then you’ll be modifying a resource that would invalidate any certificate signature on your app.

The best thing to do is o detect every time you run the app if the database file has already been copied from the app bundle (or folder) into a target folder that doesn’t have an access problem when it is time to use the database. The Application Support folder is a good place for Desktop apps, while the Documents folder is fine for Xojo Cloud and iOS apps.

For example, if our database file is named “EddiesElectronics.sqlite” and our app name is “Xojotest”, then we can add the following code fragment into the Open Event Handler of a Desktop app:

Var source As FolderItem = SpecialFolder.Resource("EddiesElectronics.sqlite")
Var name As String = app.ExecutableFile.name.NthField(".",1)

// We check if there is a folder with the App name in special Application Data
// if not, we create it and copy the database file from Resources bundle/directory
If Not (SpecialFolder.ApplicationData.Child(name).Exists And SpecialFolder.ApplicationData.Child(name).IsFolder) Then SpecialFolder.ApplicationData.Child(name).CreateFolder
If Not SpecialFolder.ApplicationData.child(name).child(source).exists Then source.CopyTo(SpecialFolder.ApplicationData.Child(name))

Try
  // Create a SQLiteDatabase instance and try to open our database file from
  // the path
  pDatabase = New SQLiteDatabase
  pDatabase.DatabaseFile = SpecialFolder.ApplicationData.Child(name).Child("EddiesElectronics.sqlite")
  pDatabase.Connect

Catch e As DatabaseException
  MessageBox e.Message
End Try

For an iOS app, the code would be:

Var source As Xojo.IO.FolderItem = xojo.io.SpecialFolder.GetResource("EddiesElectronics.sqlite")

// We check if there is our database file already copied on the Documents Sandbox folder
// if not, we copy the database file from Resources bundle/directory
If Not xojo.io.SpecialFolder.Documents.Child("EddiesElectronics.sqlite").Exists Then
  source.CopyTo(xojo.io.SpecialFolder.documents)
End If

Try
  // Create a SQLiteDatabase instance and try to open our database file from
  // the path
  pDatabase = New iosSQLiteDatabase

  Var f As FolderItem = xojo.io.SpecialFolder.Documents
  pDatabase.DatabaseFile = f.Child("EddiesElectronics.sqlite")
  Call pDatabase.Connect

Catch e As RuntimeException
  MessageBox e.Reason
End Try

If you’re working on Xojo Cloud, the code will be even shorter. First, make sure that the Copy File Build Step has the following values in the Inspector Panel:

• Destination: Contents Folder
• Subdirectory: Documents

Then, the code will be:

Try
  pDatabase = new SQLiteDatabase
  pDatabase.DatabaseFile = SpecialFolder.Documents.Child("EddiesElectronics.sqlite")
  pDatabase.connect
Catch e as RuntimeException
  MessageBox e.Reason
End Try

What about a Web app that you host? That would mean you are in control about the folder/directory you want to use to store the app resources. Thus, it wouldn’t make much sense to automatize this process (but it is certainly doable following the same principles).

3. Simplifying the process

What we have seen already works, but that means that you need to change the file database name and probably that would change on every app you build. That also means that you’ll have to write the same code snippet again and again on every new app. Wouldn’t it be great to be able to extend the SQLiteDatabase and iOSSQLiteDatabase classes in order to simplify that?

Well, you can do that! Start by adding a new Module to the example project (for example one named “DatabaseExtensions”) with a couple of methods on it. The first method will be the one executed on our Desktop, Web and Console apps, because all of these targets use the SQLiteDatabase class.

So, add a new method using the following signature in the just-created module:

OpenDatabase( databaseName as String )

It extends the SQLiteDatabase class, adding a new method that takes as parameter the name of the file we want to copy on the “work” folder/directory.

The code you should type on this method is:

pDatabase = New SQLiteDatabase

#If TargetDesktop Or TargetConsole Or TargetWeb Then

  Var source As FolderItem = SpecialFolder.Resource( databaseName )
  Var name As String = app.ExecutableFile.name.NthField(".",1)
  // We check if there is a folder with the App name in special Application Data
  // if not, we create it and copy the database file from Resources bundle/directory
  If Not (SpecialFolder.ApplicationData.Child(name).Exists And SpecialFolder.ApplicationData.Child(name).IsFolder) Then
SpecialFolder.ApplicationData.Child(name).CreateFolder
If Not SpecialFolder.ApplicationData.Child(nam).Child(Source).exists Then source.CopyTo(SpecialFolder.ApplicationData.Child(name))

  Try
    // Create a SQLiteDatabase instance and try to open our database file from
    // the path
    pDatabase.DatabaseFile = SpecialFolder.ApplicationData.Child(name).Child(databaseName)
    pDatabase.Connect

  Catch e As DatabaseException
    MessageBox e.Message
  End Try

#ElseIf TargetXojoCloud
  Try
    pDatabase.DatabaseFile = SpecialFolder.Documents.Child( databaseName )
    pDatabase.connect
  Catch e As RuntimeException
    MessageBox e.Reason
  End Try
#EndIf

Of course, we need to add the “pDatabase” property to our module too: pDatabase As SQLiteDatabase

Now, you’ll only need to use:

OpenDatabase("EddiesElectronics.sqlite")

With the method selected in the Project Browser, click on the Attributes section of the Inspector Panel (the Cog Wheel icon), and uncheck the “iOS 64” checkbox. This way, that method will not be included when compiling for iOS apps.

Do the same thing with the “pDatabase” property, so it is only compiled on the supported targets.

The second method is the one we will be using for iOS apps. The method signature would be:

OpenDatabase(databseName as String)

And typing the following fragment of code in the associated Code Editor:

pIOSDatabase = New iOSSQLiteDatabase

Var source As Xojo.IO.FolderItem = xojo.io.SpecialFolder.GetResource( databaseName )

// We check if there is our database file already copied on the Documents Sandbox folder
// if not, we copy the database file from Resources bundle/directory
If Not xojo.io.SpecialFolder.Documents.Child( databaseName ).Exists Then
  source.CopyTo(xojo.io.SpecialFolder.documents)
End If

Try
  // Create a SQLiteDatabase instance and try to open our database file from
  // the path

  Var f As FolderItem = xojo.io.SpecialFolder.Documents
  pIOSDatabase.DatabaseFile = f.Child( databaseName )
  Call db.Connect

Catch e As RuntimeException
  MessageBox e.Reason
End Try

Lastly, and with the method item still selected in the Project Browser, go to the Attributes section of the Inspector Panel and make sure that the “iOS 64” checkbox is the only one selected under the “Include In” section. This way, we make sure that the method will be compiled only on iOS targets.

And do the same thing with the “piOSDatabase”, so it is only compiled for iOS targets.

To Summarize

As we see, the use of Modules in combination with OOP Class Extension is a good way to get more flexibility when developing your apps; using a common function (or method) name no matter if you are working on Desktop, Web or iOS. Additionally, that leads to a more convenient reutilization of your codeand, of course, less code to maintain through all our projects!

(You can find this article in Spanish here)

You can further modify this technique so you can work with your databases in a mixed way; that is, where we want to simultaneously execute a query involving both an encrypted database table and an in-memory table database.

But for this example code we are only focused on opening an encrypted SQLite database (based on disk) as a new SQLite class instance, and using next a SQL sentence to create a new in-memory database (named RAMDB in the example), creating the same table on the RAM database next and then copying the data from the source table during the process.

From that time on, you will be able to use the new table on RAM at light speed!

Another SQL command you might find of interest, and that you can use in all your SQLite databases where you expect to get a gain in the read speed, is to use the exclusive mode, using for that PRAGMA LOCKING_MODE = Exclusive.

However, and focusing on the tip itself, this is the snippet of code you can use:

Var db As SQLiteDatabase = New SQLiteDatabase
db.DatabaseFile =  // Assign here a FolderItem to the SQLite database file on disk
db.EncryptionKey = "aes256:" +  // Add here a String with the same password that the one used to encrypt the data
If db.Connect = False Then
  Var re As New RuntimeException
  re.message = "Error trying to connect to the database"
  Raise re
End If
db.ExecuteSQL("PRAGMA LOCKING_MODE = Exclusive") // Improves the read access to the database

// We create a in-memory database, 'attaching' it with the disk based SQLite database
db.ExecuteSQL("attach database ':memory:' as 'RAMDB'")

// Copying all the contents from the source table
// to the newly created table on the RAM SQLite database

db.ExecuteSQL("create table RAMDB.product_table as select * from main.product_table")

As you can see, the second line of code expects a valid FolderItem instance pointing to the SQLite database on disk. In addition, you need to provide the String to the password used originally to encrypt the data on the source database. This example assumes that this has been done using the AES 256 option, stronger than the one using a length of 128 bits and the only option available before Xojo 2018r1.

Finally, in the last sentence db.SQLExecute you’ll have to change the table name you want to copy from the source database to the new RAM based one (product_table in the example).

Javier Rodri­guez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has be using Xojo since 1998. He manages AprendeXojo.com and is the developer behind the GuancheMOS plug-in for Xojo Developers, Markdown Parser for Xojo, HTMLColorizer for Xojo and the Snippery app, among others.

*Read this post in Spanish

Situations Where A Client/Server RDBMS May Work Better

Client/Server Applications

If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

A good rule of thumb is to avoid using SQLite in situations where the same database will be accessed directly (without an intervening application server) and simultaneously from many computers over a network.

So what are your options when you want to share your database?

If you want to stick with SQLite then you’ll need to put something in front of it that can handle requests from multiple client apps. The most obvious solution is to create a web service by using a web app with WebApplication.HandleURL (or HandleSpecialURL). The web app can accept requests from multiple client apps (or any type — desktop, web, mobile, etc.), fetch the data requested from the SQLite database and then send it back as JSON. This works because the web app is the only app that is connected to the SQLite database.

The Eddie’s Electronics Web Service sample shows you how you might set this up: Examples/Communication/Web Services/EddiesWebService

Another option for setting up your own database web service is to use the Aloe open-source project, which gives you a robust framework for building web services.

To learn more about database web services, check out the Making Database Web Services video.

By the way, this is also why a regular web app can safely use SQLite with multiple users — the web app manages the multiple users but is the only app that is connected to the SQLite database.

If you want to stick with SQLite but would rather not create a web service, another option to consider is to use a product that puts a database server around SQLite. CubeSQL and Valentina have products available that can do this.

Your final option is to switch to an actual database server. PostgreSQL and MySQL are popular alternatives.

ALTER TABLE

If you’ve been using SQLite for a while you probably know that the ALTER TABLE command has always been pretty restrictive. It really only let you change the table name or add new columns. You could not modify or remove columns. This meant that in order to modify or remove columns from a table you typically used a multi-step process of creating the new table the way you wanted, copying the data to it and then renaming the two tables so the new table now has the name of the original table. It was a hassle. And because this was manual it would break any triggers or views that used the old name.

Now with SQLite 3.25 you can directly rename columns on a table, which will update triggers and views as necessary.

The syntax is as you might expect:

ALTER TABLE MyTable RENAME COLUMN OldColumn TO NewColumn;

In Xojo code you send this command to the database using the SQLExecute method. Here’s an example that changes a column name:

Dim sql As String = "ALTER TABLE Team RENAME COLUMN Coach To HeadCoach;"
DB.SQLExecute(sql)

Sadly you still cannot remove a column so you’ll have to resort to the manual method described above.

Window Functions

According to the SQLite docs:

A window function is a special SQL function where the input values are taken from a “window” of one or more rows in the results set of a SELECT statement.

SQLite now has these built-in Window functions:

• row_number()
• rank()
• dense_rank()
• percent_rank()
• cume_dist()
• ntile(N)
• lag(expr), lag(expr, offset), lag(expr, offset, default)
• lead(expr), lead(expr, offset), lead(expr, offset, default)
• first_value(expr)
• last_value(expr)
• nth_value(expr, N)

This example uses the row_number function to assign a row number based on ordered City names while still ordering the overall results by team name:

SELECT Name, City, row_number() OVER (ORDER By City) AS row_num FROM Team ORDER BY Name;

Window Functions are powerful and can get complex quickly. Read more about them at the official SQLite Window Function doc page.

Xojo 2018 Release 4 includes SQLite 3.25.3 so be sure to upgrade to get access to these great new SQLite improvements. Download Xojo 2018 Release 4 for free today.

The SQLite database has just a single table called Quote with this structure:

CREATE TABLE Quote (
ID INTEGER NOT NULL,
QuoteText TEXT,
QuoteSource TEXT, 
PRIMARY KEY (ID)
);

To randomly fetch a single quote from the table, this SQL is used:

SELECT QuoteText, QuoteSource FROM Quote ORDER BY RANDOM() LIMIT 1;

As companion apps, I’ve also included simple desktop and iOS apps that call the web service to display a quote.

The raw JSON that is returned looks like this:

{"QuoteText":"Simple things should be simple. Complex things should be possible.","QuoteSource":"Alan Kay"}

I’ve published a version of this on Xojo Cloud. Access the app.

Access the web service here.

You can download the projects or check it all out on GitLab.

Add your #JustCode project to the week 9 forum conversation.

Download and check out earlier projects:

• Week 8: JumpStart App Launcher
• Week 7: Pitch Tracker
• Week 6: Bubble Popper
• Week 5: Math Quiz
• Week 4: Mini-Golf ScoreKeeper
• Week 3: Dogs Up!
• Week 2: Password Generator
• Week 1: Color Picker

Here are 8 reasons why you should be using SQLite with your apps:

1. It is fast

SQLite is an embedded database so the database engine gets built right into your app. It is also designed for incredible speed. It can handle millions of rows with ease.

2. It is typeless

Unlike other databases, SQLite does not care what type of data you put into a column. In fact, it really doesn’t use types at all! Columns are assigned an “affinity” of INTEGER, REAL, TEXT and BLOB which helps determine how they are used for queries and functions. But you can stick text data into an integer column without a problem. You can read more about SQLite’s unique handling of Data Types on their documentation page.

3. It is cross-platform

SQLite works on every platform imaginable, including: Windows, macOS, Linux, Raspberry Pi, web, iOS and Android. Additionally, the database files themselves are cross-platform. So if you create a database and populate with data on iOS, you can move the file over to Windows and be able to read, write and otherwise use it without trouble. This makes SQLite a great fit for cross-platform development tools like Xojo.

4. It is public domain

Because it is public domain, SQLite is complete free to use with no restrictions of any kind. And the full source code is readily available, of course.

5. It works with most programming languages

Most programming languages have built-in support for SQLite, including: Delphi, C, C#, C++, Go, Java, JavaScript, LiveCode, Lue, Objective-C, Perl, PHP, Python, Ruby, Visual Basic and Xojo. With Xojo you can use SQLite with macOS, Windows, Linux, web, console, iOS and Android apps.

6. It is updated often

SQLite is a mature database with few bugs, but it is updated often to ensure it remains at its best quality. If any bugs sneak in, they are quickly squashed.

7. It is fast

SQLite is so fast that it is worth saying again. Seriously, it is fast. Don’t use a text file or JSON or some other thing that will likely be much slower, especially when the files get large. Use SQLite and you’ll be happier.

8. It is used everywhere

It is a good bet that apps you rely on are using SQLite in some way. It is a great storage mechanism for preferences, general app data and can even be used as the app file format itself. For example, Apple Mail uses SQLite to save email messages and Firefox uses SQLite databases to store much of its profile information.

You can download Xojo for free to start making apps that use SQLite. For more information, check out these videos:

• Using SQLite
• SQLite Features
• Advanced SQLite

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Updated February 2024 to include Xojo Android.

One reason that SQL might rank so high is that it is not really a single language. Although the term SQL is used to refer to the default language used with every relational database, each version is different. SQL actually means Structured Query Language, not Standard Query Language as I often hear people refer to it. Every database that uses SQL also uses its own variant of SQL and these variants differ by just enough to be annoying, although the core commands are mostly the same. It reminds me of how BASIC was in the 1970s and 80s with different versions for each computer with nothing but the most basic (pun intended) compatibility between them.

Even though SQL is a programming language, it is not like languages you are likely most familiar with. You use SQL to write database queries that return sets of data so it works differently than just about any other language you might be familiar with (although some versions add some procedural commands).

For example if you wanted to process a bunch of rows in a typical language you might write code like this to loop through all the data:

For Each i As Integer = 0 To row.Ubound
 row(i) = row(i) * 2
Next

In SQL that data would be in a table and you would change the values of all the rows by using an UPDATE command:

UPDATE data SET value = value * 2;

Both effectively do a loop, but they don’t look all that similar.

Another interesting thing about SQL is that it really is a companion to any programming language you use to make apps. Since no one would ever make an actual app using just SQL, but most apps need a database of some kind, SQL becomes the 2nd language that you have to know alongside your primary language.

Xojo works with SQL by using one of its database classes to send SQL directly to the database you are using. For example, to work with a SQLite database you would use the SQLiteDatabase class for desktop, web or console app or the iOSSQLiteDatabase class for iOS apps. Those classes each have two methods to send SQL commands to the database: SQLSelect and SQLExecute. Essentially SQLSelect is used for SQL commands that return sets of data and SQLExecute is used for commands that do an action (such as create a table).

Like other programming languages, Xojo does not care what database you use nor does it care what SQL you are sending to it.

You can learn about some common SQL commands in the Database Operations topic of the User Guide at the Xojo Dev Center.

A property such as “DB As SQLiteDatabase” on the Session object works well. Then in its Open event handler, you actually connect to the database:

Dim dbFile As FolderItem = GetFolderItem("MyDatabase.sqlite")
DB = New SQLiteDatabase
DB.DatabaseFile = dbFile
If Not db.Connect Then
 ' Display an error page and log the error
 ' You should not show specifics of the error to users
 ErrorPage.Show
End If

In the rest of your project, you can refer to the database like this:

Session.DB

The second thing to remember is that because a web app can be accessed by many more users it is more susceptible to SQL Injection. To limit your exposure here, you should always use SQL Prepared Statements with any SQL statements that contain parameters with values from user-entered input.

To learn more about databases and web apps, view the Database Usage with Web Apps topic in the Dev Center and watch our Webinar: Connecting to Databases.