What's cooking

We got some requests about the things we are currently working on. With this message we would like to give you some more information.

Short Term

We are working very hard on X# 2.9. This version will most likely be released end of September. The focus of this build is: stabilizing the compiler and runtime and improving performance of the VS integration and preparing for the move to Visual Studio 2022, which will be a 64 bits version of VS and preparing our VS integration for the move to .Net Core, .Net 5 and .Net 6. These 3 versions of the .Net framework come with tools that work with a new project file format (what's called the SDK style projects).
As part of X# 2.9 we are also adding compiler support for the complete FoxPro language. Not all the runtime elements will be in place, but we will at least be able to compile all the FoxPro code. Some (unsupported) things will produce warnings.

Of course we are also fixing reported issues in the Runtime and Compiler.

Longer Term

After 2.9 we plan to work on:

Runtime

• FoxPro Database support (see below)
• Unicode / Any CPU version of the VO GUI Classes
• Unicode / Any CPU version of the VO SQL Classes
• RDD to access SQL Data with both table oriented approach and set oriented approach (see below)

Compiler

• Enhanced tuple support
• Several of the new features from C# 10 such as Global Using, File Scoped Namespaces, Null parameter checking, Required properties and the FIELD keyword inside Properties

Tools

• FoxPro project converter
• Visual Studio 2022
• .Net Core/5/6 support in the VS integration and Build System

Database Access in X#

The first versions of the XBase language all used the DBF format in various incarnations. FoxPro has added the ability to use SQL statements against DBFs, so you could mix Table oriented and Set oriented code, all based on the DBF file format, enhanced with a DBC file in which relations, constraints and other properties could be stored.

Other XBase dialects never added SQL support, but the 3^rd party product Advantage Database Server (ADS) helped: this product also added the ability to mix Table oriented and Set oriented data access for the same data.

At this moment X# handles table oriented data access against DBF files and also has a driver to access data in an ADS database.

To properly support embedded SQL for customers from the FoxPro world we need add embedded SQL to our product as well.

We have looked at how much work it would be to create this ourselves, and we have decided that we will NOT do that. Writing a SQL engine is way too much work for our small team, and it also feels a bit stupid to do so, since there are many, many good SQL engines available. Engines for small databases and engines for large databases.

Following our principle to "not reinvent the wheel" we have decided that if we want to use embedded SQL to our product then it has to be on top of an existing SQL Database engine.

Our first thought was to use ADS for this. We are already an ADS reseller and it would be not too complicated to do, since we already have an RDD layer for ADS.
But after doing some research we found that SAP (the company that owns ADS at this moment) is really not planning to do any serious maintenance, let alone development on ADS. So if we would decide to build our data solution on ADS we would be building on a product that is about to die. And since we do not expect that SAP will move ADS to open source, or even allow us to access the ADS source and keep supporting it, we decided that a move to ADS would be a move into a dead-end road.

On top of that there is the problem that the shared file access is becoming more and more a problem in a Networking environment, because of the changes that were made to the Windows operating system in the last years. This means that to setup a DBF based application with shared file access you have to be very careful to properly configure

We have therefore decided that to help FoxPro customers to move to X# and to help others to get away from DBF based shared file access we have to find a better solution.

Short term database solution for FoxPro users (project Delft)

As a short term solution for FoxPro users we are going to create a component in FoxPro that will be exposed through COM and a X# RDD that talks with this component. This component will be used to access the data in FoxPro tables, both in Table mode as well as in embedded SQL mode.
To use this component you will have to have the FoxPro runtime, but we assume that this is not a problem for FoxPro developers.
We will deliver the FoxPro layer both in source code as well in compiled format. The X# side will be both a RDD and a set of functions that talk with the FoxPro layer to execute SQL statements and also to handle runtime functions like DbGetProp(), CursorGetProp() etc.

Long term database solution for all users (project Ξάνθη =Xanthi)

Since we expect that many customers will want to move from Table based code to SQL based code we will create a new product that you could see as a replacement for ADS. For now we have given this component the name XDS (XSharp Database Server)
The idea is that we will not try to add SQL access to the DBF support, but the opposite (which is much easier by the way): to add Table support to SQL databases.
We will provide both a local solution and a client server solution.

The local solution consists of a SQL RDD that can talk with any Ado.Net database provider.  You can use this RDD both with a SQL statement or with a Table name. If you use a Table name, then the RDD will automatically expand that to Select statements. The data in this RDD is stored in memory in an Ado.Net Data table. You will be able to configure the RDD to specify which Ado.Net database provider to use. We will add an extra layer between the RDD and the database provider, in which the differences between various databases can be handled, such as for example how to specify a maximum number of rows ( TOP <n> for SQL Server, LIMIT clause for MySql etc.

The remote solution will consist of a service running on a computer in the network (the Server) that uses the same SQL RDD that is used by the local solution to talk to a database.
This database may also be a single user database such as SQLite so you will be able to access in that SQLite database that from various workstations in the network.
Workstations in the network use a special RDD to talk with this server to retrieve and update data.
We plan to make the communication between the clients and the server 2 ways. This means that when a table was updated by a user then all other users that have this table open may be notified of changes to this table.
We will most likely use the "opt-in" procedure for this: for many tables changes by others are not relevant, but for some tables (like stock tables for example) this could be really important.

We will also add a management API so you can ask the Server which clients / users have a table open. This will be similar to what is available for ADS.

Switching a client app between a Local server and a Remote Server will be just as easy as with ADS. So you can call a runtime function to do that but you can also configure things with a configuration file.