Is it possible to use non-DBF databases in Alaska+Express?
Re: Is it possible to use non-DBF databases in Alaska+Express?
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?
The eXpress train is coming - and it has more cars.
Re: Is it possible to use non-DBF databases in Alaska+Express?
Absolutely.Are you saying that PGDBE ISAM support is worth looking at?
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.
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."
- Eugene Lutsenko
- Posts: 1649
- Joined: Sat Feb 04, 2012 2:23 am
- Location: Russia, Southern federal district, city of Krasnodar
- Contact:
Re: Is it possible to use non-DBF databases in Alaska+Express?
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
https://doc.alaska-software.com/content ... ation.html
Last edited by Eugene Lutsenko on Tue Dec 28, 2021 7:43 am, edited 2 times in total.
Re: Is it possible to use non-DBF databases in Alaska+Express?
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.
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.
The eXpress train is coming - and it has more cars.
- Eugene Lutsenko
- Posts: 1649
- Joined: Sat Feb 04, 2012 2:23 am
- Location: Russia, Southern federal district, city of Krasnodar
- Contact:
Re: Is it possible to use non-DBF databases in Alaska+Express?
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.
Last edited by Eugene Lutsenko on Tue Dec 28, 2021 10:11 pm, edited 1 time in total.
Re: Is it possible to use non-DBF databases in Alaska+Express?
@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.
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.
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."
- Eugene Lutsenko
- Posts: 1649
- Joined: Sat Feb 04, 2012 2:23 am
- Location: Russia, Southern federal district, city of Krasnodar
- Contact:
Re: Is it possible to use non-DBF databases in Alaska+Express?
Licensed Xbase ++ Prof. V2.00 (international) I have. It has pgdbe.dll and pgdbe.ch
Re: Is it possible to use non-DBF databases in Alaska+Express?
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.
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: Is it possible to use non-DBF databases in Alaska+Express?
hi Tom,
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
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
greetings by OHR
Jimmy
Jimmy
- Eugene Lutsenko
- Posts: 1649
- Joined: Sat Feb 04, 2012 2:23 am
- Location: Russia, Southern federal district, city of Krasnodar
- Contact: