Porting SQLBase by Gupta to another system

Question

We use SQLBase for our development in various versions, including 12.2. Our main application is a Team Developer application (Version 7.5) that utilizes SQLBase as its database.

In addition to Team Developer, we program in C# (.NET Core). We're quite bothered by the fact that SQLBase still doesn't offer Entity Framework support. This means that we have to access the database using the old ADO.NET in our C# applications.

The issue is that we have a significant amount of code in Team Developer 7.5, which makes it not so straightforward to simply swap out the database. On the other hand, we don't want to continue developing with ADO.NET but rather with Entity Framework.

If we decide to replace the database, the challenge arises on how to access it from Team Developer without having to modify too much of the program code.

What needs to be done so we can use another database like MySQL, MariaDB, Postgre, or MS SQL Server with Team Developer 7.5? This way, we could finally access the database from .NET using Entity Framework while still utilizing the existing Team Developer code.

Thank you,

René

Answer 1

I am in no way affiliated with Gupta or SQLBase or any other dBMS vendor, but think twice and then think three times before downgrading from SQLBase.

We are going through this exact conundrum right now. NOT because of the Entity Framework thing ( OLEdB works just fine with SQLBase or SQLServer against TeamDeveloper, C# or what-ever ) and NOT because there is any issue what-so-ever with Gupta SQLBase ( in fact it outperforms SQLServer in some cases .)
But simply because Corporate in their wisdom say 'everything has to be standardized'.

So reluctantly have started the l-o-n-g process of migrating a 120Gb SQLBase, which works perfectly well, and all its Stored procs, Triggers, Indexes, FK's, 100's of builtin @functions, keywords ( SYSDATETIME ... ) to SQLServer - again, against a LARGE Gupta TeamDeveloper code base.

You are exactly right - it not so straightforward to simply swap out the database. Moving SQLBase v12.3 to SQLServer 2019 means a whole lot of work.
Main ones of note are:

1. Data types that are in slightly different formats e.g. TIME and LONG, so not a straight like-for-like.
2. Before INSERT trigger. Only SQLBase manages this properly. Difficult to find an equivalent. Least of all, both ‘row-level’ and ’statement’ level types. Nice! SQLBase Before Insert Trigger
3. ETL. Unless you use some-sort of wizard ( like the SQLServer Import/Export wizard) to assist somewhat with Export/Transfer/Load, you will go crazy.
4. ROWID. No dbms has ROWID like SQLBase. So if your app uses ROWID be prepared for a bit of work in this area. If moving to SQLServer, the closest resemblance is ROWVERSION which is a binary(8) number which tracks a relative time within the dB, not an actual time. So throughout your TD code you potentially need to convert e.g.

Select ROWID:

Return VisStrChoose( gGetBrand(  ) = DBV_BRAND_MSSQL,
    'CONVERT(VARCHAR(MAX), CONVERT(BINARY(8),' || p_sROWIDColName || '), 2 )', 
     p_sROWIDColName )

Where ROWID:

Return VisStrChoose( gGetBrand(  ) = DBV_BRAND_MSSQL,
    'CONVERT(binary(8),\'0x\' + :' || p_sROWIDBindName || ' , 1)', ':' || 
     p_sROWIDBindName  ) 

After going through this entire ETL and TD code modification process, best advice is to think twice and then three times against migrating from SQLBase. I just can't justify the the cost, stress and risk against (no)performance gain, swapping connectivity ( when OLEdB does the job ). But no doubt there will be others who think differently I suppose.

Answer 2

Thank you for your detailed answer, Steve.

I understand what you mean. The ROWID in particular causes us problems mentally, as we make extensive use of it. However, I would like to know how to address another SQL database from the Team Developer. How do you do that?

We have many other satellite applications around Team Developer that run on .NET - here I mean C# and .NET Core. These applications cannot be developed with Team Developer, or only with great effort.

Now these applications need to access SQLBase, which we have been doing via ADO.NET. It works, but you feel like you're back in prehistory. With Entity Framework, it's different: you save at least 40-50% of program code, development is much faster and you can no longer make many mistakes from the start that often happen under ADO.NET. As a result, the applications are not only developed faster, but they are also much more robust.

To make matters worse, Team Developer still does not support .NET Core, so you have to fall back on the old 4.8 (or 4.7?) framework if you need to develop DLLs with .NET.

That's really too many limitations for such an expensive product.

If we had an SQL database that supported both Team Developer and Entity Framework Core, our developer life would look much nicer and the family would be happy....