Hello everyone
As you know, months ago our beloved ADS Database engine stopped having support. There will be no new versions.
I wonder what options you have made, because I have my entire application with the ADS engine and I doubt what to do.
The logical thing is to change to another engine like the one proposed by Xbase++ PostgreSQL.
I'm sure not everyone took that path, I would like if you could recommend the solution you have selected for this problem.
Greetings to all and continue enjoying the programming
ADS
Re: ADS
There was no new ADS version since almost ten years. SAP bought the ADS because it was part of a kind of bundle. They were never really interested in improving the server. Anyway, it still runs and version 12 is stable. After SAP announced that it would also stop selling licenses, there were some interventions here in Europe. As a result, they will continue to sell the ADS through a slightly more complicated route, but probably only until the end of 2024. In any case, we are getting new licenses for now.
We are working on moving the application to the PGDBE/ISAM, which almost works very good. You may have read about some problems with multi-tenancy in this thread: viewtopic.php?f=20&t=3077
Besides this, the PGDBE is an excellent model to offer a true client-server-system, which is also very fast, extremely stable, cheap and easy to deploy. We hope to get the few left problems fixed until spring of 2024, so we can stop to deliver ADS step by step. The PGDBE is much faster, and ISAM can be mixed with real SQL.
We are working on moving the application to the PGDBE/ISAM, which almost works very good. You may have read about some problems with multi-tenancy in this thread: viewtopic.php?f=20&t=3077
Besides this, the PGDBE is an excellent model to offer a true client-server-system, which is also very fast, extremely stable, cheap and easy to deploy. We hope to get the few left problems fixed until spring of 2024, so we can stop to deliver ADS step by step. The PGDBE is much faster, and ISAM can be mixed with real SQL.
Best regards,
Tom
"Did I offend you?"
"No."
"Okay, give me a second chance."
Tom
"Did I offend you?"
"No."
"Okay, give me a second chance."
Re: ADS
Hi Mr. MIGUELON
Never used ADS but I can understand that at some point SAP just decided it is not worth developing it further anymore as use base dvindled due to technology shift.
PGDBE requires yearly license fee (since this year) for each user connection at customer:
https://www.alaska-software.com/product ... t-list.cxp
Discussion: viewtopic.php?f=15&t=3164
Mind that if you are sole user of database it might not present problems, but pGDBE might not be cooperating well when another software (web server, .net app) is reading/writing same data as it relies on set of special columns and tables across database with multiple triggers that need to be updated for simulated fixed indexes, 'deleted' and 'dbrlock' to work correctly.
Also I am not particullary sure PGBDE supports fully encrypted and protected connection to server (ssl_mode and certificate) which might be a obstacle in shared environments where any remote connect outside localhost of server is required to be encrypted.
Personally , I ditched new "DBF" developement in 2005 , went with sqlexpress since.
ANSI SQL wherever possible but various servers still have own quirks.
Moving logic from dbf->sql is not 'link and recompile' but is straight forward and doable.
At least for somehow modern aliased code.
GG
Never used ADS but I can understand that at some point SAP just decided it is not worth developing it further anymore as use base dvindled due to technology shift.
PGDBE requires yearly license fee (since this year) for each user connection at customer:
https://www.alaska-software.com/product ... t-list.cxp
Discussion: viewtopic.php?f=15&t=3164
Mind that if you are sole user of database it might not present problems, but pGDBE might not be cooperating well when another software (web server, .net app) is reading/writing same data as it relies on set of special columns and tables across database with multiple triggers that need to be updated for simulated fixed indexes, 'deleted' and 'dbrlock' to work correctly.
Also I am not particullary sure PGBDE supports fully encrypted and protected connection to server (ssl_mode and certificate) which might be a obstacle in shared environments where any remote connect outside localhost of server is required to be encrypted.
Personally , I ditched new "DBF" developement in 2005 , went with sqlexpress since.
ANSI SQL wherever possible but various servers still have own quirks.
Moving logic from dbf->sql is not 'link and recompile' but is straight forward and doable.
At least for somehow modern aliased code.
GG
MIGUELON wrote: ↑Mon Oct 09, 2023 5:36 pm Hello everyone
As you know, months ago our beloved ADS Database engine stopped having support. There will be no new versions.
I wonder what options you have made, because I have my entire application with the ADS engine and I doubt what to do.
The logical thing is to change to another engine like the one proposed by Xbase++ PostgreSQL.
I'm sure not everyone took that path, I would like if you could recommend the solution you have selected for this problem.
Greetings to all and continue enjoying the programming
Re: ADS
Thank you very much for your opinions, I was surprised that Alaska is charging PGBDE which makes me rule out this path.
Although my application has traditional DBF code, it also has a lot of SQL code attacking the ADS DB
I also use Sqlexpress to attack other databases such as MYSQL and Microsoft SQL.
It is clear to me that sqlexpress is a good option, now I have to decide which database to use:
PostgreSQL
MySQL
What database do you recommend that is free?
Although my application has traditional DBF code, it also has a lot of SQL code attacking the ADS DB
I also use Sqlexpress to attack other databases such as MYSQL and Microsoft SQL.
It is clear to me that sqlexpress is a good option, now I have to decide which database to use:
PostgreSQL
MySQL
What database do you recommend that is free?
Re: ADS
hi,
---
you can use
ODBC
ADO / DbOLE
native LibPQ.DLL for PosgreSQL or MyLibSQL.DLL for MySQL
you know ODBC
ADO is a COM Interface and "Connection-String" is like ODBC. you will get "Recordset" as Object
native Version need a "Wrapper", for *.DLL, most made by using OT4XB
---
there is a Version from Hector Pezoa (patito) in Express++ Forum for MySQL
phpbb3/viewtopic.php?t=783
for PostgreSQL you can use Pablos libpq4xb.zip which i have upload in German Xbase++ Forum
https://www.xbaseforum.de/viewtopic.php?t=8564
both Native Version does NOT support ISAM Style
as i know both are free
---
you can use
ODBC
ADO / DbOLE
native LibPQ.DLL for PosgreSQL or MyLibSQL.DLL for MySQL
you know ODBC
ADO is a COM Interface and "Connection-String" is like ODBC. you will get "Recordset" as Object
native Version need a "Wrapper", for *.DLL, most made by using OT4XB
---
there is a Version from Hector Pezoa (patito) in Express++ Forum for MySQL
phpbb3/viewtopic.php?t=783
for PostgreSQL you can use Pablos libpq4xb.zip which i have upload in German Xbase++ Forum
https://www.xbaseforum.de/viewtopic.php?t=8564
both Native Version does NOT support ISAM Style
greetings by OHR
Jimmy
Jimmy
Re: ADS
In my use case I prefer PostgreSQL ; It is harder and stricter but at end it offers really a lot of performance and features.
Skip MySQL and use MariaDB instead which is my 2nd choice
Mariadb is fully mysql compatible but is very actively developed where MySQL's owner Oracle
is not active much and can have some nasty licensing surprises .
So Mariadb is also a very good choice.
Read: https://kinsta.com/blog/mariadb-vs-postgresql/
Both PostgreSQL and Mariadb work really well on server side with python, php and (xb2net+sqlexpress)
I do regulary use MSSQL and some Oracle (choice by customers because they have contract DB support that knows mostly those two).
Hint: Try to stick to full ANSI SQL as much as possible and use db server you are comfortable to use.
Skip MySQL and use MariaDB instead which is my 2nd choice
Mariadb is fully mysql compatible but is very actively developed where MySQL's owner Oracle
is not active much and can have some nasty licensing surprises .
So Mariadb is also a very good choice.
Read: https://kinsta.com/blog/mariadb-vs-postgresql/
Both PostgreSQL and Mariadb work really well on server side with python, php and (xb2net+sqlexpress)
I do regulary use MSSQL and some Oracle (choice by customers because they have contract DB support that knows mostly those two).
Hint: Try to stick to full ANSI SQL as much as possible and use db server you are comfortable to use.
MIGUELON wrote: ↑Tue Oct 10, 2023 1:50 pm Thank you very much for your opinions, I was surprised that Alaska is charging PGBDE which makes me rule out this path.
Although my application has traditional DBF code, it also has a lot of SQL code attacking the ADS DB
I also use Sqlexpress to attack other databases such as MYSQL and Microsoft SQL.
It is clear to me that sqlexpress is a good option, now I have to decide which database to use:
PostgreSQL
MySQL
What database do you recommend that is free?
Re: ADS
I agree with all this. That is the right thing to do.k-insis wrote:
PGDBE might not be cooperating well when another software (web server, .net app) is reading/writing same data as it relies on set of special columns and tables across database with multiple triggers that need to be updated for simulated fixed indexes, 'deleted' and 'dbrlock' to work correctly.
Moving logic from dbf->sql is not 'link and recompile' but is straight forward and doable.
At least for somehow modern aliased code.
Best regards,
Slavoljub Damnjanovic
SD-SoftDesign, Alaska Software Technology Partner
https://www.sd-softdesign.com
https://www.sd-softdesign.rs
Slavoljub Damnjanovic
SD-SoftDesign, Alaska Software Technology Partner
https://www.sd-softdesign.com
https://www.sd-softdesign.rs
Re: ADS
We moved a really large, very complex application to PostGreS using PGDBE/ISAM. Migration was about one hundred times faster than moving all navigational code to SQL. The result works excellent, is much faster than any ADS version ever was, is easy to maintain and very reliable. Access from other applications is no problem, and allowing other applications to write data is a problem as it always is: This is simply not a good idea, cause having this can kill your data not only on the technical side. Besides, Alaska implemented mechanisms to even deal with foreign applications writing in your PG-databases. And you can mix ISAM with native SQL, transforming the application step by step to native SQL. Besides all that, the amount of money Alaska bills for the DBE is not worth a discussion. Don't forget: The server is for free. I don't know what conditions you had/have for buying the ADS, of which the newest version is more than 10 years old. It was never cheap.
Best regards,
Tom
"Did I offend you?"
"No."
"Okay, give me a second chance."
Tom
"Did I offend you?"
"No."
"Okay, give me a second chance."
Re: ADS
Tom -
I would really enjoy working on a migration project from ADS to PGDBE.
Bobby and I talked about doing this with his Taxi Medallion software, but the payback can take years to recover if the migration takes more than 1 year.
I would really enjoy working on a migration project from ADS to PGDBE.
Bobby and I talked about doing this with his Taxi Medallion software, but the payback can take years to recover if the migration takes more than 1 year.
The eXpress train is coming - and it has more cars.