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.

This article will show you how to automatically record queries and commands in any Xojo database class to help you debug and improve database operations by using method overriding. This will help you:

• Debug SQL operations faster by seeing exactly what’s being executed.
• Spot errors in your SQL queries or parameters before they become runtime issues.
• Gain transparency into your app’s database behavior.

By the end of this tutorial, you’ll have a clear understanding of:

• Method overriding: What it is and how you can use it to extend built-in Xojo classes.
• Subclassing database classes: Learn how to develop a custom database class with added logging functionality to improve database management and tracking.
• Logging SQL commands and parameters: Discover how to effectively capture and log database operations such as SELECT, INSERT, and DELETE to enhance visibility and improve database performance.

What is Method Overriding?

Method overriding, a fundamental concept in object-oriented programming (OOP), lets you customize how a subclass implements its superclass’s methods. In Xojo, this powerful feature allows you to enhance built-in classes without modifying their original code, ensuring you preserve core functionality while adding your own features.

How Method Overriding Works in Xojo

Let’s break it down step by step with a simple example. Imagine you’re working with the SQLiteDatabase class, and you want to modify the behavior of the ExecuteSQL method to log every SQL command executed.

1. Create a Subclass:
   • Create a new class in Xojo and set its Super to SQLiteDatabase. This means your new class inherits all the properties and methods of SQLiteDatabase.
2. Override the Method:
   • In your new subclass, define a method and from the Method Name picker, select ExecuteSQL.
   • Add your custom logic, like logging the SQL command to the Xojo debugger.
3. Call the Original Method:
   • Use the Super keyword to call the original ExecuteSQL method in the superclass. This ensures the original behavior is preserved alongside your custom logic.

Extending Xojo’s SQLiteDatabase with Method Overriding

Let’s enhance Xojo’s SQLiteDatabase class by creating a subclass that automatically logs SELECT queries and their parameters. To make this process easier, use the built-in “Full-Text Searching 5” example project, which already includes various database operations.

1. Create the MySQLiteDatabase Subclass

1. From the Insert menu, select Class.
2. Name the new class MySQLiteDatabase.
3. In the Inspector, set the Super field to SQLiteDatabase.

This tells Xojo that MySQLiteDatabase will inherit all the behavior of SQLiteDatabase, allowing you to override its methods.

2. Override the SelectSQL Method

Now, you’ll override the SelectSQL method in your MySQLiteDatabase class. This method is used for SELECT queries, so you’ll add logging to display the query and its parameters in the debugger.

Public Function SelectSQL(query As String, ParamArray values() As Variant) As RowSet
  // Log the SELECT query
  System.DebugLog("[DEBUG] SelectSQL called: " + query)
  
  // Log the parameters (if any)
  If values.LastIndex >= 0 Then
    Var stringValues() As String
    For Each v As Variant In values
      stringValues.Add(v.StringValue) // Convert Variant to String
    Next
    System.DebugLog("[DEBUG] Parameters: " + String.FromArray(stringValues, ", "))
  End If

  // Call the original SelectSQL method
  Try
    Return Super.SelectSQL(query, values)
  Catch error As DatabaseException
    // Log any errors
    System.DebugLog("[ERROR] DatabaseException: " + error.Message)
    Raise error // Re-raise the exception so the app can handle it
  End Try
End Function

3. Replace the Database Property

Now that you’ve created the MySQLiteDatabase subclass, you need to update the example project to use it.

1. Open Window1 in the Project Browser.
2. Locate the DB property in Window1. It is currently defined as DB As SQLiteDatabase:
3. Change the type of DB from SQLiteDatabase to MySQLiteDatabase. To do this:
   • Select the DB property.
   • In the Inspector, update the Type field to MySQLiteDatabase.

Additionally, under the Opening event of Window1, change DB = New SQLiteDatabase to DB = New MySQLiteDatabase.

This replaces the original SQLiteDatabase with your custom subclass, ensuring all database operations now use your overridden SelectSQL method.

4. Test the Logging

With the subclass in place, run the project and test the logging functionality.

1. Run the project.
2. Perform a search in the app’s UI. Each search generates a SELECT query using the SelectSQL method.
3. Check Xojo’s Messages Panel for output. You should see the SQL query and its parameters logged.

Example Output:

[DEBUG] SelectSQL called: SELECT highlight(ftstest, 0, '<', '>') FROM ftstest WHERE ftstest MATCH 'know' ORDER BY rank;

Additional Enhancements

Now that you’ve created a foundation for extending Xojo’s database classes by logging queries with your custom subclass, it’s time to think about how you can take this further. Below are several ideas for additional enhancements that will make your subclass more robust, versatile, and useful for debugging and performance monitoring.

Log Additional Methods

While you’ve started with the SelectSQL method, your app likely performs other database operations, such as INSERT, UPDATE, DELETE, or even transactions. You can override methods like ExecuteSQL to log these operations along with their parameters. Extending the logging functionality to these key methods ensures a complete picture of all database activity.

Additionally, logging transactional methods like BeginTransaction, CommitTransaction, and RollbackTransaction can help you trace when database changes are grouped together and ensure data integrity.

Tip: You can incorporate the Log4Xojo project.

Support for Multiple Database Classes

If your app uses different database types, such as MySQLCommunityServer or PostgreSQLDatabase, you can generalize your logging functionality to work with all of them. This can be achieved by creating a base class for logging that inherits from Database and then extending it for specific database types. This approach ensures consistency and reusability across different database systems.

Monitor Query Performance

Tracking the time it takes for queries to execute can give you valuable insights into your application’s performance. By measuring the duration of each query, you can identify slow queries and optimize them for better efficiency. Additionally, you could log a warning if a query takes longer than a specified threshold, helping you catch performance issues early.

Automatically Retry Failed Queries

Sometimes, database operations fail due to transient errors, such as network interruptions or locked tables. Implementing retry logic for failed queries can make your app more resilient. For example, you could attempt a query up to three times before logging it as a failure. This is particularly useful for apps that rely on remote database servers, where connectivity issues are more likely.

Add Context-Specific Metadata

Including additional context in your logs can make them more meaningful. For example, you might log:

• The name of the method or function that triggered the query.
• The user ID or session ID (if applicable) for tracking user-specific database activity.
• Tags or labels to group related queries or transactions.

This kind of metadata makes it easier to understand the “why” behind a query, not just the “what.”

Wrapping It All Up

Congratulations! You’ve taken a deep dive into one of the most powerful techniques in Xojo development: extending built-in classes, like SQLiteDatabase, to meet your specific needs. By following the steps in this tutorial, you’ve learned how to override methods, create a custom database subclass, and log SQL queries for better debugging and transparency.

What’s Next?

If you enjoyed this tutorial, we’d love to hear from you! Share your thoughts, your customizations, or any challenges you faced in the Xojo forums. If you’ve built something amazing using this technique, let us know—we’d love to feature your work in our community showcase.

Keep coding, keep innovating, and as always, happy developing!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• 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

There are many ways to develop with Xojo and use database servers. You might be working on a multi-user desktop application that stores data in a database. Or you’re creating a multi-user Xojo Web application that needed to be scaled up to a couple of running instances – and use a database for data storage. Or maybe you’ve written a mobile application that connects to a Backend REST API – again possibly written in Xojo (e.g. with the open source Express, or with Xojo Web).

As a Developer

When working on such projects, you’re facing quite some challenges with the various database servers available.

• You need to have a local development environment running the database server(s).
• You want to test your application against a newer version of a database server.
• A customer reports an issue occurring with a database server version that you don’t have installed.

Developer Machine

I like to have a development machine that’s as cleaned up as possible. So I don’t like the idea of installing various servers just for some tests. It’s so tedious to clean up, update to other versions, and remove all remnants of an installation when no longer required. And I don’t want to have various services running on my machine that I don’t need all the time, as they’re just eating precious memory and slowing down the machine.

Wouldn’t it be cool if there was an easy way to spin up various database servers when needed without all the hassle? Well there is – let’s have a look at Docker and Docker Compose.

Docker Compose and Database Servers

With Docker, it’s a breeze to develop with and for various database servers.

What is Docker?

If you haven’t heard of Docker, go ahead and read their excellent Documentation: Docker – Overview. Or read my previous Guest Blog Post: Running Xojo Web Applications in Docker. I’m just going to repeat and quote some basics from the Overview to get a very brief introduction:

Docker is an open platform for developing, shipping, and running applications. It provides the ability to package and run an application in a loosely isolated environment called a container. The isolation and security allow you to run many containers simultaneously on a given host. Containers are lightweight and contain everything needed to run the application, so you do not need to rely on what is currently installed on the host.

A Docker Container is a runnable instance of an image. You can create, start, stop, move, or delete a container. By default, a container is relatively well-isolated from other containers and its host machine. You can control how isolated a container’s network, storage, or other underlying subsystems are from other containers or from the host machine. A container is defined by its image as well as any configuration options you provide to it when you create or start it.

Docker Compose is a tool for defining and running multi-container applications. It is the key to unlocking a streamlined and efficient development and deployment experience. Compose simplifies the control of your entire application stack, making it easy to manage services, networks, and volumes in a single, comprehensible YAML configuration file. Then, with a single command, you create and start all the services from your configuration file.

Docker Compose for Database Server and Administration

This sounds great. Just write a YAML configuration file, and run a database server on the host (meaning: your developer machine). And be able to start, stop, delete at any time – without messing with Preferences, Launch Daemons.

But why Docker Compose for “multi container applications”? Well, the database server is one part: one application, one running docker container. And as a developer you most likely want to have some database administration tool running, too – which again is running as an own isolated container. And in order to have both available with a single command (or by simply pressing “run” or “stop”) we’re going to “compose” these two parts so that they fit and work together.

How to Run a Database Server and Administration Tool with Docker Compose

Let’s do that and install and configure three database servers which we then can use to develop an application in Xojo to connect to:

• PostgreSQL & pgAdmin
• cubeSQL & cubeSQL Web Admin
• MariaDB & phpMyAdmin

Note: All the following configuration files are available on GitHub: jo-tools/docker.

Requirements

Obviously we need to have Docker installed. And since we’re talking about being a Developer and doing this on our own development machine we’re going to install Docker Desktop. With Docker Desktop you can later easily start, stop and delete the Containers we’re going to create. When it’s empty (no containers installed), it looks like this:

We’re now ready to get started…! But wait – there is one thing we should talk about before.

Data Storage

Where are the database servers going to store their data(bases)?

If you want to know all the details, head over to the Docker Documentation: Manage data in Docker. What we need to know is this:

Docker has two options for containers to store files on the host machine, so that the files are persisted even after the container stops: Volumes, and Bind Mounts.

Why is this important to know? Well, let’s assume we create and start a Container “PostgreSQL Server”. Think of that Container as a “virtual machine” or a bag. It can save data in there just fine. But once we delete that container or throw away that bag, then all it’s data is gone, too.

That might well be intended…! For example if you just wish to play with some tool and don’t care to keep the data you’re creating with it. However, if you’d like to easily back up that data, or update a Container from “v.15” to “v.16” and keep the previous data – then that’s when Volumes and Bind Mounts are needed.

Quoted from the docs:

Volumes
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. They are completely managed by Docker.

Bind Mounts
Data is stored in a directory on the host machine, which is mounted into the container.

Okay – two options, so what’s the difference?

The Bind Mounts are a folder on the host (your developer machine). So you can easily see them, view/edit/backup the data. It might be an option if you need easy access to these files.

The Volumes are the preferred way, since they are managed within Docker. Using Docker Desktop you can view the contents – but it’s not that simple to view/edit files in there as you can’t mount it as a volume or folder on your developer machine. Of course there are some more advanced ways, which I’m not going to explain here. So definitely the best option when you don’t need to work with and open these files with other tools, too. The other reason we don’t need Bind Mounts for our database servers is that we can just use their administration tools to import/export data such as database dumps.

Alright – now let’s start and set up some database servers.

PostgreSQL Server & pgAdmin

Let’s use the example setup with Volumes for Data Storage from here: GitHub: jo-tools/docker – local-postgres-volumes.

Download the docker-compose.yml file from my GitHub Repository and place it in a folder on your machine.

I’m going to save it in: ~/Docker/local-postgres-volumes

YAML file: docker-compose.yml
A word of precaution when writing and editing YAML files:

• Indentation is done by spaces (not by tabs!)
• Indentation has to be exact (use always 2 spaces), or expect to get syntax errors

Let’s look at the content of this docker-compose.yml.

x-common-timezone: &services-timezone Etc/UTC

name: local_postgresql
services:
  postgres-server:
    container_name: postgresql
    hostname: postgresql
    image: postgres:16-alpine
    volumes:
      - postgresql_data:/var/lib/postgresql/data
    environment:
      TZ: *services-timezone
      PGTZ: *services-timezone
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres
    networks:
      - local_postgresql_net
    ports:
      - 5432:5432
    restart: unless-stopped

  pgadmin:
    container_name: pgadmin4
    hostname: pgadmin4
    image: dpage/pgadmin4:8
    environment:
      TZ: *services-timezone
      PGADMIN_DEFAULT_EMAIL: admin@postgres.sql
      PGADMIN_DEFAULT_PASSWORD: admin
      PGADMIN_CONFIG_UPGRADE_CHECK_ENABLED: "False"
      PGADMIN_CONFIG_SERVER_MODE: "False"
      PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED: "False"
    networks:
      - local_postgresql_net
    volumes:
      - pgadmin4_data:/var/lib/pgadmin
    ports:
      - 5433:80
    restart: unless-stopped
    depends_on:
      - postgres-server

volumes:
  postgresql_data:
    driver: local
    name: postgresql_data
  pgadmin4_data:
    driver: local
    name: pgadmin4_data

networks:
  local_postgresql_net:
    name: local_postgresql

In the first hierarchy there are:

• x-common-timezone: &services-timezone Etc/UTC

In this extension we define a scalar value for the timezone, which will be used for the environment variables in both services. The template uses UTC (which is also the default for Docker). You can change it to your timezone, e.g.: Europe/Zurich. This might be desired if you’re going to select the current date/time from the database server later.
• name: local_postgresql

That’s the name of this “setup”. We’ll later see this in Docker Desktop’s Containers. There we can also start/stop/delete this setup at any time.
• services:

There are two services in this setup: postgres-server and pgadmin
• volumes:
And two volumes: one for the database server, and one for the administration tool.
• networks:

Both these two containers will be in the same network.

When we look at the two services postgres-server and pgadmin4:
• container_name:
The name of the Container. We’ll later see this as a sub-element of this docker-compose setup named local_postgresql
• hostname:
Think of a container as a virtual machine. Every one has its hostname. And the two containers in this setup we have placed in the same network. So they can talk to each other via hostname.
•image:
That’s basically the content of the container. We’re going to install:
• postgres:16-alpine
PostgreSQL Server in Version 16.x, running on Linux Alpine (a very lightweight one).
• dpage/pgadmin4:8
pgAdmin 4 in Version 8.x as the administration tool.
• environment:
Here the environment variables of the containers are being defined. TZ defines the Timezone, and uses the value we have defined in the extension on the very top. The other Environment Variables contain the defaults and standards – here used when the containers are being started the first time to define the default logins, users and passwords. Our PostgreSQL server will have a default login with both username and password: postgres. pgAdmin we have configured to auto-login without authentication required, and disabled update checks.
• networks:
Remember – both in the same one (defined below)
• volumes:
The format here is: volume_name:/mount/in/folder
We’re going to see these volumes later in Docker Desktop. They’ll contain the data. Usually the documentation of the Docker Images explain which folders are being used to save data, so they can be mounted here to either a Volume (or a Bind Mount).
• ports:
The format here is: host-port:container-port
For PostgreSQL Server we’re using 5432:5432, meaning that we can connect on our developer machine to Port 5432 (and this will be forwarded to the container running PostgreSQL Server, listening on Port 5432 inside the Container). pgAdmin is running on Port 80 within the Container, but we connect to it from our developer machine via Port 5433.
• restart: unless-stopped
This basically means: if you have this setup running and reboot your host (developer machine), then this setup gets restarted automatically. If you’re going to stop this setup (because you don’t need it at the time), then it’ll be stopped after a reboot, too.

Start Docker Compose Setup

As we can’t use Docker Desktop to start a Docker Compose setup (maybe this feature will be added in the future) we have to use Terminal. Change Directory to where the docker-compose.yml file is and type: docker-compose up -d

The referenced Images will be pulled, the defined network created and the Containers started.

Open the Dashboard in Docker Desktop and look at the Containers – you’ll find our setup named local_postgresql with the two Containers postgresql and pgadmin4:

They are currently up and running.
If you want to stop this setup simply press the button under “Actions”. It then will be stopped even after a reboot. And should you need to run the setup again later, just hit the button “Run” here.

Under Volumes we see the created ones:

You can click on one to see it’s contents – here the data of postgresql:

Connect With PGADMIN4
Either switch again to “Containers” and click the link “5433:80” in the column “Port” of the Container “pgadmin4” in Docker Desktop, or open a browser and go to 
http://localhost:5433.

Since this is the first launch of pgAdmin4 we need to add a server – I have given it the name “Docker”:

In the register “Connection” we have to enter the connection data:

Username and password are the default ones (remember the environment variables?). And for this local developer setup I have chosen to save the password.

The most interesting part is the hostname.

• You can’t use localhost here!

  The reason is simple: pgAdmin is running in a Container (think of it again as a virtual machine), so it’s “localhost” is the Container running pgadmin4. Not your developer machine, and not the Container where postgres is running.
• I have entered: host.docker.internal

  This is explained in the Docker Documentation: networking:
The host has a changing IP address, or none if you have no network access. We recommend that you connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host.
• Another option would be to just use the hostname: postgresql

  And why does this work? Well – we have configured these two containers to be in the same network, and the server is running in the host named “postgresql”.

And here we go: Let’s expand the entries of the just added server “Docker”, click on the main database “postgres” and execute a query: SELECT version();

Connect with Xojo
We’re ready to use Xojo now and work on applications using our local PostgreSQL Server.
Let’s connect to our local development server running in Docker. As a simple test I have placed the following code in the Opening event of a Label:

Var db As New PostgreSQLDatabase
db.Host = "localhost"
db.UserName = "postgres"
db.Password = "postgres"
db.Port = 5432

Call db.Connect

Var rs As RowSet = db.SelectSQL("SELECT version();")
Me.Text = rs.Column("version").StringValue

Additional Information

You’ve seen how to easily spin up PostgreSQL with Docker Compose and connect to it with pgAdmin4 and Xojo. What else do we need to know?

Images
You’ll find available Images on Docker Hub. In the above setup we have used postgres and pgAdmin4. If you look at them on Docker Hub you’ll see that they provides many images. One can select them by Tag. The used Tag “postgres:16-alpine” here means that we get the latest version 16 (e.g. 16.2, and some month later maybe 16.3 or 16.4). If for some reason we want to get exactly version 16.1, then we can use the corresponding Tag, e.g. “postgres:16.1-alpine”.

A Setup using Bind Mounts
If you’re going to try the docker-compose.yml with Bind Mounts from here: GitHub: jo-tools/docker – local-postgres-bindmounts, then you’ll notice the difference in the configuration here:

volumes:
  - ./postgresql_data:/var/lib/postgresql/data

You won’t get a Volume in Docker, but instead this will create a folder named postgresql_data in the folder where you’ve placed docker-compose.yml and launched the setup with docker-compose up -d.

Docker Compose Commands
We’ve already mentioned that the first launch of a Docker Compose setup will require Terminal. The following commands are to be executed in the same directory containing the yaml file, too:

docker-compose up -d
This looks for the file docker-compose.yml, pull the images, do all the setup and launch the containers. You can also use this command to restart this setup, should you have stopped it.

docker-compose stop
Stops all services in this setup. Or do it using the buttons in Register “Containers” in Docker Desktop.

docker-compose down -v
This removes all services and volumes from this setup. Use this to get rid of all Containers, Volumes AND data. Haven’t we mentioned that – it’s super easy to clean up
You could also click the Delete buttons in Docker Desktop in both “Containers” and “Volumes” (and optionally “Images”).
If you omit the option “-v”, it will leave the Volumes in place. This might be of interest if you intend to keep the data, in case you’re going to spin up this setup again some time later.

docker-compose down
docker-compose pull
docker-compose up -d
These 3 commands will first tear down the existing containers (leaving volumes and data in place), then pull the latest versions from Docker Hub and set everything up again. Remember that we have used the Image “postgres:16-alpine”, and currently got PostgreSQL 16.2? Once PostgreSQL 16.3 is available we can execute these commands and get the latest version. Again super easy to update, isn’t it?

cubeSQL & cubeSQL Web Admin

Another popular database server for Xojo is cubeSQL. It basically adds multi-user handling (including groups, privileges, und much more) on top of SQLite.

cubeSQL is a fully-featured and high-performance relational database management system built on top of the SQLite database engine.

It is the ideal database server for both developers who want to convert a single user database solution to a multi-user project and for companies looking for an affordable, easy to use and easy to maintain database management system.

You’ll find an example setup for Docker Compose here: GitHub: jo-tools/docker – local-cubesql-volumes. To connect with Xojo you need a plugin, which can be downloaded from GitHub: cubesql/cubeSQLAdmin

cubeSQL Web Admin – Written with Xojo Web

cubeSQL has a desktop application for administration, which you’ll find in the above GitHub Repository, too. As you can guess a desktop based application is not quite convenient when it comes to an easy docker compose setup.

While I’m using Xojo for desktop and console applications for quite some time, I’ve never really used Xojo Web before. That’s why I took this opportunity and gave it a try. And behold – in very short time (most functionality in just a weekend’s leisure time) I’ve written “Xojo Web Admin“. It’s been a pleasure to create something more than just some simple examples – I like the idea of creating something useful even while learning something new. And I’ll be honest – I’ve found a couple of bugs in Xojo’s Web Framework while writing cubeSQL Web Admin, but most of them are already fixed and implemented for the next Xojo version. And finishing and polishing the project to make it available to the public also took an additional couple of evenings.

cubeSQL Web Admin is Open Source – so go ahead and have a look at the source (or even better: contribute to it by adding more features, find bugs and fix them). There might be some things of interest, such as:

• How to use Xojo Web to build an app that runs in a Docker container.
 See also this Guest Blog Post: Running Xojo Web Applications in Docker
  • A new feature added while developing GitHub: cubeSQL Web Admin: The Post Build Script builds a “Multi Architecture” Docker Image (linux/amd64 & linux/arm64v8) by building the Xojo Web App for BuildTargets Linux x86 64-bit and Linux ARM 64-bit. This allows to support running the Docker Image natively on Macs with both Intel and Apple processors.
• How to use Launch Arguments and Environment Variables for configuration. This allowed us to configure the Environment Variables in our Docker setup to preconfigure the connection data.
• The approach with subclassed WebContainer’s that implement the WebDataSource Interface. The quite generic base class cntDatasourceBase can be configured to:
  • be searchable (Main Window shows/hides the WebSearchField if the subclassed Container defines to (not) be searchable).
  • define which Fields of a RowSet should be displayed (cubeSQL uses special custom commands for administration, so we can’t select distinct columns ourselves, and there’s no paging within these custom commands).
  • define virtual Fields, which will be shown in the WebListbox, but aren’t part of a RowSet. Internally the base class uses a Dictionary Array which gets built from the RowSet, so one could use it with other external DataSources, too.
  • show the Fields in the WebListBox, while allowing each Container to override the default behaviour (see for example the Databases, which use a WebListboxImageRenderer for a virtual field – depending on a couple of Columns in the RowSet an appropriate Status Icon is being displayed).

To connect to this cubeSQL setup with Xojo I have placed the following code in the Opening event of a Label:

Var db As New CubeSQLServer
db.Host = "localhost"
db.UserName = "admin"
db.Password = "admin"
db.Port = 4430

Call db.Connect

Var rs As RowSet = db.SelectSQL("SHOW INFO FOR KEY server_version")
Me.Text = rs.Column("value").StringValue

MariaDB & phpMyAdmin

MariaDB Server is a high performing open source relational database, forked from MySQL.

You’ll find an example setup for Docker Compose here: GitHub: jo-tools/docker – local-mariadb-volumes.

I’m not going to explain much more here about MariaDB (MySQL) or phpMyAdmin here – I think you should figure out easily how to launch the Administration tool and connect to the server when looking at the contents of this docker-compose.yml. But, since it’s a widely used and well-known database server, I wanted to provide a setup for this combo, too.

As a simple test for this setup I have placed the following code in the Opening event of a Label:

Var db As New MySQLCommunityServer
db.Host = "127.0.0.1"
db.UserName = "root"
db.Password = "mariadb"
db.Port = 3306

Call db.Connect

Var rs As RowSet = db.SelectSQL("SELECT version() AS version;")
Me.Text = rs.Column("version").StringValue

For some reason the connection needs an IP Address or a Hostname (and doesn’t work with localhost).

A Word of Caution

The above setups are only intended as a local test setup – don’t use them like this for production. Even on a local developer machine you shouldn’t run the services with these simple initial login credentials, so go ahead and change them.

The purpose is to explain how Docker Compose works, and how it can help developers to easily setup up local environments to work on database applications. And of course these examples might well be a head start to those that haven’t used Docker before.

That’s All Folks!

I hope this brief introduction of how to use Docker and Database servers for and with Xojo has been helpful to some, food for thought to others.

Jürg Otter is a long term user of Xojo and working for CM Informatik AG. Their Application CMI LehrerOffice is a Xojo Design Award Winner 2018. In his leisure time Jürg provides some bits and pieces for Xojo Developers.

• 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.

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.

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

In API 2.0, SQLSelect became SelectSQL and SQLExecute became ExecuteSQL. Additionally API 2.0 automatically uses prepared statements. Now, while they perform much the same actions, there are enhancements which make code much simpler to create and read. This is because they implement Prepared Statements under the hood.

For Example, this API 1.0 code:

Dim ps As PreparedSQLStatement
Dim rs As RecordSet

ps = Session.db.Prepare("SELECT * FROM users WHERE emailaddress = ?;")
ps.BindType(0, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_STRING)
ps.Bind(0, "wayne@axisdirect.co.nz")

rs = ps.SQLSelect()

Session.UserID = rs.Field("id").IntegerValue

Becomes:

Var rs As RowSet

rs = Session.db.SelectSQL("SELECT * FROM users WHERE emailaddress = ?;" _
 ,"wayne@axisdirect.co.nz")

Session.UserID = rs.Column("id").IntegerValue

Seven lines of code become just four and in my opinion the second is much easier to follow. A prepared statement is not required (as it is implemented under the hood), and the bind type is automatic.

That SELECT statement does not have many bindings, but here is an INSERT statement that does – API 1.0 code

Dim ps As PreparedSQLStatement
ps = Session.db.Prepare("INSERT INTO reports (title, scheduletype, dayofmonth, dayofweek, sunday, monday, tuesday, wednesday, thursday, friday, saturday, nextrun, reportfile, deliverymethod, suspended) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)")

ps.BindType(0, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_STRING)
ps.BindType(1, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_INT)
ps.BindType(2, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_INT)
ps.BindType(3, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_INT)
ps.BindType(4, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)
ps.BindType(5, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)
ps.BindType(6, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)
ps.BindType(7, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)
ps.BindType(8, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)
ps.BindType(9, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)
ps.BindType(10, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)
ps.BindType(11, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_STRING) ' This is a datetime value, but we're going to bind a SQLDateTime String
ps.BindType(12, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_STRING)
ps.BindType(13, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_INT)
ps.BindType(14, MSSQLServerPreparedStatement.MSSQLSERVER_TYPE_TINYINT)

ps.Bind(0, TitleField.Text)
ps.Bind(1, ScheduleTypeMenu. ListIndex)
ps.Bind(2, If(ScheduleTypeMenu. ListIndex = 2, Val(DayOfMonthField.Text), 0)
ps.Bind(3, If(ScheduleTypeMenu. ListIndex = 1, Val(DayOfWeekField.Text), 0)
ps.Bind(4, If(WeekDay(0).Value, 1, 0)
ps.Bind(5, If(WeekDay(1).Value, 1, 0)

ps.Bind(6, If(WeekDay(2).Value, 1, 0)
ps.Bind(7, If(WeekDay(3).Value, 1, 0)
ps.Bind(8, If(WeekDay(4).Value, 1, 0)
ps.Bind(9, If(WeekDay(5).Value, 1, 0)
ps.Bind(10, If(WeekDay(6).Value, 1, 0)
ps.Bind(11, NextRunField.DateValue.SQLDateTime)
ps.Bind(12, ReportFileField.Text)
ps.Bind(13, DeliveryMethodMenu.SelectedIndex)
ps.Bind(14, 1)

ps.SQLExecute()

If Session.db.Error Then
  Break ' The insert statement failed for some reason - this should only happen during debugging.
End If

Becomes:

Var sql As String

sql = "INSERT INTO reports (title, scheduletype, dayofmonth, dayofweek, sunday, monday, tuesday, wednesday, thursday, friday, saturday, nextrun, reportfile, deliverymethod, suspended) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)"

Try
  Session.db.ExecuteSQL(sql, _
   TitleField.Value, _
   ScheduleTypeMenu.ListIndex, _
   If(ScheduleTypeMenu.ListIndex = 2, Val(DayOfMonthField.Text), 0), _
   If(ScheduleTypeMenu.ListIndex = 1, Val(DayOfWeekField.Text), 0), _
   If(WeekDay(0).Value, 1, 0), _
   If(WeekDay(1).Value, 1, 0), _
   If(WeekDay(2).Value, 1, 0), _
   If(WeekDay(3).Value, 1, 0), _
   If(WeekDay(4).Value, 1, 0), _
   If(WeekDay(5).Value, 1, 0), _
   If(WeekDay(6).Value, 1, 0), _
   NextRunField.DateValue.SQLDateTime, _
   ReportFileField.Value, _
   DeliveryMethodMenu.ListIndex, _
   1)

Catch Err As DatabaseException
  Break ' The insert statement failed for some reason - this should only happen during debugging.
End Try

Again, a huge reduction in coding and a more readable result. You will also notice the use of a try/catch block. API 2.0 methods raise exceptions and during debugging these are invaluable as they break on the exception rather than later when your logic bug bites

The API 2.0 SelectSQL method also returns a RowSet rather than a RecordSet. The RowSet is iterable unlike the RecordSet and that makes it much more user friendly. I can’t tell you how many times I’ve run a project only to find it just sits there using all the CPU cycles it can because I forgot to call the MoveNext method.

I understand that many people using Xojo on Windows probably aren’t targeting MS SQL Server, but I believe this is changing. And as more developers target Windows and MS SQL Server, the fixes and improvements that come with API 2.0 will make this easier for them. I know they are making my life a lot easier.

Oh, and by the way, before this update this application would start with a memory usage of about 100MB and grow to >500MB over the week and then I would restart the service. Updating this project to API 2.0 resulted in ongoing memory usage of between 7.5 and 8.5MB for the running application. I suspect this is a combination of my improved coding and improvements under the hood by Xojo.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

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.

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)

Apparently, in the fictional 23rd century relational databases and SQL are still in use not only by the United Federation of Planets but also by alien probes from the future! Normally Star Trek creates some technobabble gibberish for this sort of thing, so I certainly found this line surprising. Perhaps the writers thought it was just gibberish or that it would sound like gibberish to the average person.

But anyone who uses databases knows that SQL Injections can be a real issue. A SQL Injection refers to an issue when your app inadvertently allows a user to inject their own SQL into one of its database queries. Read this post on how to avoid them.

Essentially, it can occur when you use standard string concatenation to create an SQL query from user-provided text. If you prompt the user for a name so you can show their tasks, for example then you’d normally get SQL like this:

SELECT * FROM Task WHERE Name = 'Paul';

But what if the user provides malicious input, such as this: Paul’ OR 1

Then your concatenation code might create SQL like this:

SELECT * FROM Task WHERE Name = 'Paul' OR 1;

And this will return a lot more data. Obviously this is a simple example, but this type of exploit can be much more sophisticated. And apparently also something that alien probes from the future might try to use.

You can avoid this problem by taking advantage of a feature called database binding so that you do not use string concatenation to generate the SQL. With Xojo you do this by creating a prepared statement with placeholders for input strings and then let the database create the query itself using binding. So the SQL might look something like this:

SELECT * FROM Task WHERE Name = ?

Read the User Guide topic to more about how to avoid SQL injection by using prepared statements with your Xojo database code:

UserGuide:SQL Injection

And of course, relevant XKCD.

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.

Dim db As New MySQLCommunityServer

db.Host = "somehost"
db.port = <port # for your mysql server>
db.DatabaseName = "somedbname"
db.UserName = "someuser"
db.Password = "somepassword"

If db.Connect Then

  Dim rs As RecordSet = db.SQLSelect("select @@Global.version")

  While rs <> Nil And rs.eof <> True

    // and here you get a row with the value selected

    rs.MoveNext

  Wend
End If

There are a whole host of possible items you can select this way.  See all your options at the MySQL Docs site.

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.

Multiple Databases Supported

Xojo supports a wide variety of databases, including: SQLite, PostgreSQL, MySQL, Microsoft SQL Server and Oracle.

In addition, you can use ODBC to connect to other databases such as Access (JET), FoxPro, FileMaker, Firebird and even IBM iSeries (DB2). You’ll always have access to your data using Xojo, read more about connectivity between Xojo and your preferred database.

Flexible Form Design

Xojo includes dozens of controls available for desktop, web and mobile apps. You can use these controls to design any type of user interface that you can imagine. You’ll find controls for buttons, check boxes, popup menus, text fields, text areas, graphics, tabs, progress, lists, HTML, images and more.

Simple and Powerful Programming Language

How can a language be both simple and powerful? Xojo is simple because its language is small, focused and object-oriented. It is powerful because its framework, which is also object-oriented, includes robust capabilities you can start using right away, including: native user interface controls, file management, graphics, text processing, networking, threading and more.

Database Binding for Security

Xojo has built-in support for SQL binding so that you can avoid the security risks that can occur with SQL injection, a type of security vulnerability that can occur when you create SQL statements using simple string manipulation.

Reporting

What good is data without a way to report on it? Xojo desktop apps can use the built-in reporting tool to help you design and display simple reports. And there are also many 3rd party reporting products available for those with more advanced needs or for other platforms.

Documentation

If you are new to this, read about how to get started on database apps in this earlier post. Xojo has an in-depth User Guide, a complete Language Reference, and a playlist of videos about using databases with Xojo. The User Guide even has sections on migrating from Microsoft Access, Visual FoxPro and FileMaker!

Try Xojo Free

Xojo is free to use for learning and development. Download and try it today and see for yourself!

Free
PostgreSQL is completely free to use. It has a license similar to BSD and MIT which means you can use it with no restrictions whatsoever, unlike other open-source databases such as MySQL.

Easy to setup
Want to test PostgreSQL on macOS? You can use Postgres.app to get a working PostgreSQL database just by running a single app with no installation required at all.

Even if you need to install PostgreSQL, easy installers are also available with pre-built binaries for Windows, macOS and Linux.

If you need more support you can turn to EnterpriseDB, which offers PostgreSQL with support.

Often you don’t even have to bother with installing PostgreSQL because many server hosts automatically provide it as an option that you can easily turn on or configure. For example, with Xojo Cloud, you can enable PostgreSQL with a single click in the Control Panel.

With other hosting companies you may have to install PostgreSQL yourself, but steps are often provided. For example, Digital Ocean provides these steps for installing PostgreSQL in CentOS 7.

Powerful
PostgreSQL has all the professional-grade features you expect in a server database. You can have multiple users, multiple databases, stored procedures, robust types for your tables, views, full SQL, backups and more.

Secure
PostgreSQL has SSL for secure connections. It is updated regularly and is used by many, many organizations ensuring that it is kept up-to-date with security updates as necessary. You can find the full PostgreSQL security report here.

Flexible

You can use PostgreSQL with any programming language. Because PostgreSQL is so ubiquitous, nearly any programming language easily connects to it. In Xojo, your code would look like this:

Dim pg As New PostgreSQLDatabase
pg.Host = “sheep”
pg.DatabaseName = “Mary”
pg.Port = 5432
pg.UserName = “lamb”
pg.Password = “foo”
If pg.Connect Then
  // Connected
End If

In PHP, your code looks like this:

$dbconn3 = pg_connect("host=sheep port=5432 dbname=mary user=lamb password=foo");

Lots of Tools
Working with PostgreSQL is much easier when you use a GUI tool. There are many, many tools available such a pgAdmin, Navicat and SQLPro. For a complete list, refer to the PostgreSQL tool wiki page.

Documentation
If you do happen to get stumped while working with PostgreSQL, you’ll find there is lot of information and documentation available. The official documentation is available online here.

There are also dozens of books and information that you can easily find on how to use PostgreSQL, many of which are listed here.

Want to learn even more? Watch this PostgreSQL video.

As the PostgreSQL site says, it is “the world’s most advanced open source database”. Once you give it a try, you will most definitely agree!

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.

Sometimes you hear that PostgreSQL is case-insensitive, but it isn’t really. What it actually does is convert your SQL to lowercase by default. So take a look at this SQL:

SELECT FullName FROM Person

This gets converted to:

SELECT fullname FROM person

That is nice if you happen to like to write your queries with mixed casing.

But you’ll start to run into a problem if you’ve actually created the table with case-sensitive names, which happens when you use quotes around the names. For example, consider these SQL CREATE statements:

CREATE TABLE person (fullname VARCHAR(100), address VARCHAR(100))

CREATE TABLE Person (FullName VARCHAR(100), Address VARCHAR(100))

CREATE TABLE "Person" ("FullName" VARCHAR(100), "Address" VARCHAR(100))

In the first two examples, you get a table called “person” with two columns called “fullname” and “address”. That may not be obvious in the second example since the names are not lowercase, but remember that PostgreSQL converts your SQL to lowercase for you.

In the last example, the names are in quotes so their case is maintained. This means you’ll get a table called “Person” with two columns called “FullName” and “Address”. Now what happens if you try to run a query with a table called “Person”? Well, using SQL like this:

SELECT FullName FROM Person

you’ll get a syntax error:

ERROR: relation “person” does not exist
LINE 1: SELECT FullName FROM Person

This is because PostgreSQL is converting “Person” to “person”, but there is no table called “person”. It is actually called “Person”.

To avoid this error you instead have to write the SQL with quotes like this:

SELECT "FullName" FROM "Person"

Obviously that can start to become a bit of a pain, so the moral of the story is don’t use quotes when creating tables or writing SQL queries so that everything is created as lowercase and things will work like you probably expect. You’ll especially want to pay attention to any tools you use to create SQL for you. If you use a tool’s UI to create a table and have a habit of typing in mixed case, the tool might generate SQL (or even the table itself) for you using quotes, which as you can see could mess you up later.

Learn more about PostgreSQL in the Xojo Dev Center.

Download MP3.

Show Notes

• BKeeney Software
• Microsoft SQL Server
• Microsoft SQL Server on Linux
• Navicat
• Data Definition Language
• Tree swing Requirements
• ActiveRecord

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.

Generally, you work with databases by sending SQL commands. In particular the SELECT command is used to get data from a database. These SELECT statements are simply built out of text. This is normally not a problem, but it can be when you start to concatenate text to build an SQL statement.

In particular, the risk occurs when you build an SQL statement with user-supplied input. For example, say you prompt the user for some information to filter (it doesn’t matter what) and then create an SQL statement by concatenating what they typed. You might have code that looks like this:

Dim sql As String
sql = "SELECT * FROM Tasks WHERE UserName = 'Paul' AND Title = '" + userValue " + "'"

If the user types “Mow” as the value then the SQL looks like this:

SELECT * FROM Tasks WHERE UserName = 'Paul' AND Title = 'Mow'

But what if the user types something a bit more nefarious, such as “Mow’ OR 1;”? This now results in SQL that looks like this:

SELECT * FROM Tasks WHERE UserName = 'Paul' AND Title = 'Mow' OR 1;'

Now there are two SQL statements. The first one returns all the data in the table (because of the “OR 1”) and the second statement (just a ‘) is likely just ignored. So now your app is displaying lots of data that the user was not meant to see (perhaps data from other users in this case).

This is called SQL Injection because the user was able to inject their own SQL into your query, all because you were using concatenation.

So how do you avoid this? Instead of concatenating, you use the databases built-in ability to create prepared statements by binding values to parameters. For Xojo, you use the appropriate PreparedStatement class for your database. In the case of SQLite, you would use SQLitePreparedStatement.

To start you first declare the SQL to have parameters:

Dim sql As String
sql = "SELECT * FROM Tasks WHERE UserName = 'Paul' AND TITLE = ?"

Then you create a prepared statement, bind the value and send it to the database:

Dim ps As SQLitePreparedStatement
ps = MyDB.Prepare(sql)
ps.BindType(0, SQLitePreparedStatement.SQLITE_TEXT)
ps.Bind(0, userValue)
Dim rs As RecordSet
rs = ps.SQLSelect

Update (October 10, 2019):

If you’re using API 2.0 in 2019r2 or later, the above code is even simper:

Var results As RowSet = MyDB.SelectSQL(sql, userValue)

Because the value is treated as a parameter, if evildoers again try to inject their own SQL, the resulting SQL sent to the database is actually equivalent to this:

SELECT * FROM Tasks WHERE UserName = 'Paul' AND TITLE = 'Mow'' OR 1;'"

This is a valid SQL statement that will simply return no rows.

Any apps that embed user input into SQL statements should always use prepared SQL statements. Do not think you can just write your own code to sanitize user input as this still poses a risk.

And there are also reasons to use prepared statements even when SQL injection is not a concern: some databases cache the parsing of the database command, which can result in some performance improvements if the database command is used repeatedly in the app.

Reference: SQL Injection in the Xojo User Guide