ADS vs PG

[unixkd]

Hi all

A lot have been said about ads and postgresql most especially on this vibrant forum.

I am just been curious, are there comparable reason for want to choose one over the other for a large enterprise projects.

Thanks

Joe

[Tom]

Hi, Joe.

ADS has reached EoL twelve (!) years ago. Meanwhile, it's hard to buy licenses, and this may get harder. Modern operating systems are not officially supported, since they were not known when the development stopped. On the technology side, ADS is more than just outdated. It's technology from the nineties. In shorter words: Bad idea. Don't use the ADS.

PG is a robust, fast, very good and extremely cheap (costs: zero) modern SQL-server. The question is not whether to use it or not, but how to use it. You have a wide range of models, starting at the ISAM-emulation with the PGDBE and ending at direct, native use of SQL. You may begin with PGDBE and end with native use.

[rdonnay]

ADS is a very reliable solution for both ISAM and SQL, however Tom is right that there will be no support in the future.

If you are interested in updating an existing application to Client/Server, with SQL and ISAM capabilities, PostGreSql via PGDBE is finally ready for prime time.
This has been a Hurculean effort by the Alaska team over many years of development and was much more difficult to develop than ADSDBE.
The ADS database server was always ISAM where the PostGreSql database server was always SQL, so implementing ISAM in PGDBE was not easy to do, yet Alaska did it.

[Auge_Ohr]

hi,

PG is a robust, fast, very good and extremely cheap (costs: zero) modern SQL-server.

You may begin with PGDBE and end with native use.

to use PGDBE you have to pay extra Lizence so it is NOT "free".
Only when use Postgre "native" it is "free"

[Tom]

The PostGreSQL server is for free.

[SlavkoDam]

As it is known, Alaska PGDBE is ISAM emulation which uses 5-7 extra columns per each table to maintain this emulation, and an extra time for updating these columns in each database operation. So, it is much slower than native (true) PostGreSQL, especially in large data processing. Besides, there are a number of problems in PGDBE that are many times discussed on this forum (only one schema, deleting records, locking tables, filters, ... ), which are never fixed by Alaska and will never be. The truth is that ISAM to SQL cannot be done 100% reliably. Not to mention cost for client licenses, what Jimmy said.
If you want PostGreSQL, use it native and avoid Alaska PGDBE.

[Tom]

So, it is much slower than native (true) PostGreSQL, especially in large data processing.

This is simply not true. It isn't much slower just because of the few columns to service in addition. In most of the situations, you can't even measure the difference. PGDBE is slower with very large databases used without indexes. In a standard application like PoS, it is even faster than direct db access in a network (from two or three workstations on). And the bottleneck isn't the data access speed.

All those permanently repeated arguments sound like on sundays in church. This is not church. The aim here is to find quick, functional, pragmatic solutions that also takes care of the skills available. Your skills are different.

[rdonnay]

This is not church.

If you came to America and listened to what politicians are selling these days, you would think America was church.

We shouldn't be having discussions about what is the solution until first we discuss what is the problem.

PGDBE was developed to solve the problem of applications consisting of thousands of lines of legacy ISAM code, and decades of development time, needing extended lifetime with minimum recoding.
I think that it is remarkable how well that was accomplished considering what a monumental task it has been.

PGDBE was not meant for new applications however it still works well using XBase++ as the base language, eXpress++ as the GUI language, and SQL as the database language.

[Tom]

PGDBE was not meant for new applications

But it can be used for them. If you don't want to learn SQL and if you don't want to deal with statements, result sets and so on, you may keep the navigational way and use legacy methods to implement new applications. I wouldn't do so, but it can be done.

[SlavkoDam]

You both forgot discussions on these topics:

http://bb.donnay-software.com/Donnay/vi ... =20&t=3260
http://bb.donnay-software.com/Donnay/vi ... =20&t=3269
http://bb.donnay-software.com/Donnay/vi ... =20&t=3268

Rodger wrote:
Screen 1 shows the amount of time it takes to open 16 tables using DBFCDX. (.34 seconds).
Screen 2 shows the amount of time it takes to open the same 16 tables using PGDBE. (9.15 seconds).
Screen 3 shows the amount of time it takes to do a search through several tables and fill an array of record numbers based simply on dbSeeks() using DBFCDX (50.94 seconds).
Screen 4 shows the amount of time it takes to do a search through several tables and fill an array of record numbers based simply on dbSeeks() using PGDBE (1931.04 seconds).
Neither of these searches used indexes that have UDFs. This is a deal killer for my customer.
I have always been suspicious that PostGreSql ISAM emulation was not a feasible solution for migration of existing code. I have been asked, by my client, to help with a migration from ADSDBE to PGDBE. Now, I am not convinced that this migration can succeed. I have determined that data performance follows an exponential curve with PostgreSQL. The practical limit appears to be 500,000 records.

k-insis wrote:
PGDBE by my account causes additional writes, not only on main table, but on special columns and calls stored procedures all the time for each insert, update, delete. One insert may be write to main table, another two or three writes more for indexes and such. So it can slow down to crawl.
I honestly tried PGDBE but outside some longer testing decided not to use it. It was slow, limited to single type of DBMS. We switched to pure SQL, but with SqlExpress as link to ODBC and have been using it ever since. And in years I found there isn't that much work to actually go from ISAM to SQL.

Joe wrote:
I had always believed that PGDBE is a misadventures and unnecessary. SQL Express or PowerSql is the way to go. Features like ability to use .net and vcl components would be more useful than this road to nowhere called PGDBE.

Cris wrote:
I have no experience with PGDBE and I don't plan to do anything with it. I'm afraid it isn't used by a lot of developers, so there is almost no experience with it in the field. It looks to me as Tom is the only who succeeded to implement it rather successfully? After 16 year they suddenly announced that there is a yearly license fee for the use per user. I'm wondering how much developers are taking this route to move to SQL?