Hi Folks,

I am still sitting on the fence, waiting for some encouragement to move 
from Version 1.9 to Version 2.0. I have tried the evaluation and I 
cannot see any benefit yet to switch. I am a heavy user of ADS and I am 
still using  the DBF table format without any problems. The quasi SQL 
works extremely well and provides all the requirements that we have. I 
can not even get the quasi ISAM in Postgresql to come even close in 
performance in Version 2.0.

We tried all the dbfupsizing and  found the overall performance to be 
horrendously slow, no matter what, or how the indexes were created.

Frank at Alaska could not tell me why I should switch, maybe someone out 
there
can convince me it would be a good idea to  do so.

I am open to ideas, Postgresql is a fine database system, I think it 
gets a bad rap with xbase++ 2.0.

Love to hear from you.

Regards to all

Chris C.

On 6/17/2022 6:02 PM, Chris Chambers wrote:
> Hi Folks,
> 
> I am still sitting on the fence, waiting for some encouragement to move 
> from Version 1.9 to Version 2.0. I have tried the evaluation and I 
> cannot see any benefit yet to switch. I am a heavy user of ADS and I am 
> still using  the DBF table format without any problems. The quasi SQL 
> works extremely well and provides all the requirements that we have. I 
> can not even get the quasi ISAM in Postgresql to come even close in 
> performance in Version 2.0.
> 
> We tried all the dbfupsizing and  found the overall performance to be 
> horrendously slow, no matter what, or how the indexes were created.
> 
> Frank at Alaska could not tell me why I should switch, maybe someone out 
> there
> can convince me it would be a good idea to  do so.
> 
> I am open to ideas, Postgresql is a fine database system, I think it 
> gets a bad rap with xbase++ 2.0.
> 
> Love to hear from you.
> 
> Regards to all
> 
> Chris C.

Chris,

I think there are two main reasons to look into using Postgresql...

1. The future of ADS is uncertain.  SAP is still committed to supporting 
it, for the time being, but they do not seem to be interested in adding 
new features or benefits to it.  Development has pretty much stalled.

2. You have to purchase ADS licenses, and pass that expense along to 
your customers.  Postgresql is open source, and free, so switching to 
Postgresql could potentially generate more profits, or enable lower/more 
competitive pricing, if you pass the savings along.

That being said, I don't have a lot of hope for the PGDBE.  I've been 
experimenting with it since 2017.  At one point, Alaska Software had my 
application installed on one of their test servers, so they could 
experiment directly with it. They were never able to get it to work at a 
production level. It was too slow, and some screens just didn't work at 
all.

If a developer were building a new Xbase++ application from scratch, I 
think they could use the PGDBE to create an application that would 
perform at a production level.  You would have to abandon ISAM type code 
altogether, and use SQL queries throughout.  However, if you have an 
application like mine, built over 20+ years with hundreds of thousands 
of lines of code using ISAM navigation, I don't think it will ever work 
as intended. That's not entirely surprising, given the tremendous 
differences between ISAM and SQL database architectures.

The only way I can envision effectively migrating from ADS to Postgresql 
is to convert all ISAM code to SQL queries with ADS and the switch over 
to Postgresql. For me, that would basically entail rewriting my entire 
application, which took me over 20 years to build, and is being added to 
every day.  I'm not sure that is realistically possible.  I would love 
to wrong about that.

Chris Carmac

Hello Chris and Chris,

the history is a bit complicated but yes, I can report a success.
I'm very rarely in this newsgroup - I live and work in Germany, so I'm 
mostly active in the German XBase++ User Forum, e.g. for Postgres:
https://www.xbaseforum.de/viewforum.php?f=114
Although most of the content is in German, you might still find it worth 
a look.

Back to your question: I agree with Chris Carmac regarding the main 
advantages of Postgres. I would also add:
3. The availability of tools such as pgAdmin4 for database 
administration, backups and ad-hoc queries. I also found dbForge Data 
Compare a brilliant tool for comparing whole databases ("What changed 
since yesterday?").
4. The potential for interoperation with other systems based upon other 
software technologies - at least for read-only access, but also see 
Alaska's new "ILX" forum, e.g.
https://ilx.alaska-software.com/index.php?ams/structure-schema-data-manipulaton-of-isam-emulated-tables-with-native-sql.81/

In my case the application is the internal ERP system (two overlapping 
programs for financial and material management) of the electronic 
engineering firm for which I work (with about 30 employees). According 
to cloc it has about 32k lines of code (after being recently thinned-out 
to remove most conditional compilations). We have over 50 ISAM tables; 
the total data volume is not extremely large (a DB dump is about 60 MB) 
- the complexity lies more in the connections between them as 
implemented in the code. It has been developed over the past 30 years; I 
have been responsible for about the last 15 years. Originally in 
Clipper, ported to Xbase++ and ADS in 2007-2009, still in text-mode.

The live system is running with Postgres since May 2021. In the first 
year (until May 2022) I did have quite a lot of stress mainly due to 
bugs in PGDBE which have now been fixed - Alaska has done a lot of work 
in this area and vastly improved it over the last couple of years. 
Alaska Support were a great help. I would now regard PGDBE as being 
quite robust and the performance as good.

The one area with which I sometimes still have problems is regarding the 
limited support for filters. The users are mostly engineers, and used to 
having an extremely flexible filter function where they can enter Xbase 
expressions. I get around this by "compiling" the most commonly used 
syntax to SQL WHERE clauses and using a relation via __record to the 
original workarea, but my code for this is not comparable to a 
professional compiler construction. "Just for fun", the code is here:

https://www.xbaseforum.de/viewtopic.php?f=114&t=11562&sid=1c281e46f2415c4fa47f0bcea1fa6377
However, our system is probably untypical in this regard - for most 
applications this is probably unnecessary, it does cause problems, and 
the filter restrictions in concrete cases can be avoided much more easily.

Hope this helps!

Best regards,
David Mackenzie

Leipzig, Germany


Am 22.06.2022 um 15:31 schrieb Chris Carmac:
> On 6/17/2022 6:02 PM, Chris Chambers wrote:
>> Hi Folks,
>>
>> I am still sitting on the fence, waiting for some encouragement to 
>> move from Version 1.9 to Version 2.0. I have tried the evaluation and 
>> I cannot see any benefit yet to switch. I am a heavy user of ADS and I 
>> am still using  the DBF table format without any problems. The quasi 
>> SQL works extremely well and provides all the requirements that we 
>> have. I can not even get the quasi ISAM in Postgresql to come even 
>> close in performance in Version 2.0.
>>
>> We tried all the dbfupsizing and  found the overall performance to be 
>> horrendously slow, no matter what, or how the indexes were created.
>>
>> Frank at Alaska could not tell me why I should switch, maybe someone 
>> out there
>> can convince me it would be a good idea to  do so.
>>
>> I am open to ideas, Postgresql is a fine database system, I think it 
>> gets a bad rap with xbase++ 2.0.
>>
>> Love to hear from you.
>>
>> Regards to all
>>
>> Chris C.
> 
> Chris,
> 
> I think there are two main reasons to look into using Postgresql...
> 
> 1. The future of ADS is uncertain.  SAP is still committed to supporting 
> it, for the time being, but they do not seem to be interested in adding 
> new features or benefits to it.  Development has pretty much stalled.
> 
> 2. You have to purchase ADS licenses, and pass that expense along to 
> your customers.  Postgresql is open source, and free, so switching to 
> Postgresql could potentially generate more profits, or enable lower/more 
> competitive pricing, if you pass the savings along.
> 
> That being said, I don't have a lot of hope for the PGDBE.  I've been 
> experimenting with it since 2017.  At one point, Alaska Software had my 
> application installed on one of their test servers, so they could 
> experiment directly with it. They were never able to get it to work at a 
> production level. It was too slow, and some screens just didn't work at 
> all.
> 
> If a developer were building a new Xbase++ application from scratch, I 
> think they could use the PGDBE to create an application that would 
> perform at a production level.  You would have to abandon ISAM type code 
> altogether, and use SQL queries throughout.  However, if you have an 
> application like mine, built over 20+ years with hundreds of thousands 
> of lines of code using ISAM navigation, I don't think it will ever work 
> as intended. That's not entirely surprising, given the tremendous 
> differences between ISAM and SQL database architectures.
> 
> The only way I can envision effectively migrating from ADS to Postgresql 
> is to convert all ISAM code to SQL queries with ADS and the switch over 
> to Postgresql. For me, that would basically entail rewriting my entire 
> application, which took me over 20 years to build, and is being added to 
> every day.  I'm not sure that is realistically possible.  I would love 
> to wrong about that.
> 
> Chris Carmac