bb.donnay-software.com

I am very comfortable working in SQL, but converting a very large application will require good ISAM support.

Are you saying that PGDBE ISAM support is worth looking at?

Are you saying that PGDBE ISAM support is worth looking at?

Absolutely.

Upsizing is a little tricky if you want to provide some comfort and control in this (see below). After that, a connection/default session (which may be recyled) must be established for every thread, like with the ADS - it's almost the same. Looking up for tables with "File()" must be translated to "Table()", with some additions. Everything looking for files must be checked, and everything using pathes (like explained in my message above). Pack and reindex are still needed. There are still some issues with filters, as I mentioned, but relations, scopes, locates and all the other stuff runs perfect. Performance is great, even locally. But our tables don't have more than around 200,000 records in maximum, so I can't tell much about performance with really big databases. But a guy in the german forum also uses PGDBE (with big tables) and is also very satisfied with it.

Is there a portable version of PGDBE (which does not need to be installed)? You say that PGDBE can be downloaded for free. Where can I download PGDBE? Is there a description of the features and examples of using PGDBE (especially in ISAM)? Is it possible to use PGDBE it locally, not via the network? The network - it can be later, in the future.

https://doc.alaska-software.com/content ... ation.html

I'm looking for a big challenge like this.
I need something interesting to do this winter.

Now we have to convince the Taxi Management company to go down this road with us.
They are inclined to want to invest in a web-based application written in a more mainstream language.

We don't think that it makes any sense.
They still need the big back office program and don't understand it because they are new investors and only see the world of the web.

On the page: https://doc.alaska-software.com/content ... onent.html there is a message about the maximum size of the dbf file: File size Limited to the offset for record locks, default is 1 GB (10^9 bytes). Somehow very little, only 1 GB. Maybe I don't understand something? And how much is the maximum not by default? According to the maximum number of fields, it is clearly written: unlimited.

@Eugene: The PGDBE is not for free, it's the database engine for that, coming with Xbase++ (2.0). The PostGreSQL server is for free. It maybe installed anywhere you want, even locally or somewhere in the internet. Look here: https://www.postgresql.org/

But. The ISAM emulation is not optimized regarding network traffic. All selects on tables are always "SELECT *", so all columns of a table are acquired. There are some other aspects concerning the emulation which cost traffic. Native SQL maybe faster. But if you are looking for a good, fast and reliable migration causing low code changes, this is the way.

Licensed Xbase ++ Prof. V2.00 (international) I have. It has pgdbe.dll and pgdbe.ch

Look at the samples for PGDBE-migration. You can migrate the MDI-sample yourself, there is a how-to in the help files. The PGDBE works with PostGreS up to version 13.

hi Tom,

Tom wrote: ↑Tue Dec 28, 2021 7:21 amBut our tables don't have more than around 200,000 records in maximum

you seems not to understand my Question when i as for "Tuple" > 2^32

when your Table have max 200.000 ROW you can not get "Result-Set" with "Tuple" > 2^32
if you have a 100 GB Table and got a "Result-set" > 2 GB it does NOT work under 32 Bit.

like FSEEK() i got 0 when Pointer is > 2^32
so i have to "upgrade" my native LibPG.DLL to use ULongLong2Double() / Double2ULongLong() from Ot4Xb

---

i agree that is is not a good "Result-Set" when got so many Record(s)
but it IS still a 32 Bit "Problem" to work with Pointer > 2^32 under 32 Bit

I'll just check it out.