Is there a portable ADS with an ISAM interface?

[Eugene Lutsenko]

Thank you, Slobodan! Is there a portable (not installed) version of PostgreSQL? Is it possible to work in PostgreSQL in the ISAM interface (SQL is inconvenient for me, because I always did everything in ISAM)?

[Tom]

Hi, Eugene.

You can install a PostGreS-server wherever you want (and on any kind of system, including Mac and Linux), and you may connect to it via internet. You can install PostGreS locally aswell. What do you want? Do you want to have a portable (moveable) database? So, different servers on different sites synchronizing the same data?

[Eugene Lutsenko]

Hi, Eugene.

You can install a PostGreS-server wherever you want (and on any kind of system, including Mac and Linux), and you may connect to it via internet. You can install PostGreS locally aswell. What do you want? Do you want to have a portable (moveable) database? So, different servers on different sites synchronizing the same data?

Hello, Tom! It's all great and great! But in the long run. And now all I need is the support of local databases by this server. But I can't install this server on the computers I want to use it on. These are computers of the university and generally unknown users all over the world: http://aidos.byethost5.com/map5.php. Therefore, the server must be portable. In general, everything is as usual in dbf, only under the server and without the usual restrictions on the size and dimensions of databases. Locally, operationally, in ISAM

[Tom]

Where is your application installed, Eugene? On those computers? If you are able to install a desktop application, you maybe able to install a db server aswell.

[Eugene Lutsenko]

Where is your application installed, Eugene? On those computers? If you are able to install a desktop application, you maybe able to install a db server aswell.

My app is portable. To install it, you just need to expand the archive. You can use it even if it is on an external disk. The archive can be downloaded here: http://lc.kubagro.ru/aidos/_Aidos-X.htm . Here is the source text of Alaska+Express and nothing else: http://lc.kubagro.ru/__AidosALL.txt. There are several external modules on Delphi.

The project is here: https://disk.yandex.ru/d/Qp-j2X7-hMIvSA
There are also many graphic and pdf files in the Eidos system, which are in the installation archive.

[k-insis]

Privjet!

What you came to is that you bumped to limits of DBF and in xbase too.

IMHO apart to moving to SQL there is no sensible option to manage large datasets in 32bit as alaska xbase has file size 2^32 bytes limit and dbf format 2038 (foxdbe) field limit, but all that was already said here.

On "just click and run" on classroom computers.

For use without install there are "Portable" versions of some sql databases (mariadb and postgres) that can be downloaded, extracted and started on localhost ( https://sourceforge.net/projects/pgsqlportable/ ) but am not exactly sure if that works on highly limited user accounts too.

Second obstacle would be connector:

for first use ODBC driver has to be installed with admin privileges to system, but after that registry entry for datasouce can be added as "user defines data source" with simple entry into registry even in limited user and that one can point to any server that is reachable by tcp/ip (including localhost)

But you do not need to connect via ODBC, which adds overhead as you can use direct access dll (libmysql for mysql/mariadb is example of that) that is significantly faster (order of magnitude on amount of data transfer) to use, but it requires some additional coding (xbase interface is already available).

But mind neither of those two will remove 32bit memory limit for in-memory datasets on local machine (afaik xbase turns belly up way before it uses 2GB of ram).

Option is to move final data crunhing of matrices to 64bit compiled (xHarbour is xbase compatible language already on 64bit) . Python is good and easy to implement on those too.

If you can do data crunch part with ANsi SQL on sql server than apart from how much memory and disk is available - there are no practical limits.

And as Mr. Slobodan said, postgresql is good and fast choice (fully open source & free) . It is less forgiving to bad sql than mysql though.

[Eugene Lutsenko]

Privjet!

What you came to is that you bumped to limits of DBF and in xbase too.

IMHO apart to moving to SQL there is no sensible option to manage large datasets in 32bit as alaska xbase has file size 2^32 bytes limit and dbf format 2038 (foxdbe) field limit, but all that was already said here.

On "just click and run" on classroom computers.

For use without install there are "Portable" versions of some sql databases (mariadb and postgres) that can be downloaded, extracted and started on localhost ( https://sourceforge.net/projects/pgsqlportable/ ) but am not exactly sure if that works on highly limited user accounts too.

Second obstacle would be connector:

for first use ODBC driver has to be installed with admin privileges to system, but after that registry entry for datasouce can be added as "user defines data source" with simple entry into registry even in limited user and that one can point to any server that is reachable by tcp/ip (including localhost)

But you do not need to connect via ODBC, which adds overhead as you can use direct access dll (libmysql for mysql/mariadb is example of that) that is significantly faster (order of magnitude on amount of data transfer) to use, but it requires some additional coding (xbase interface is already available).

But mind neither of those two will remove 32bit memory limit for in-memory datasets on local machine (afaik xbase turns belly up way before it uses 2GB of ram).

Option is to move final data crunhing of matrices to 64bit compiled (xHarbour is xbase compatible language already on 64bit) . Python is good and easy to implement on those too.

If you can do data crunch part with ANsi SQL on sql server than apart from how much memory and disk is available - there are no practical limits.

And as Mr. Slobodan said, postgresql is good and fast choice (fully open source & free) . It is less forgiving to bad sql than mysql though.

Thank you very much! And is it possible to learn more and more specifically how to do it on postgresql .

[Auge_Ohr]

hi Eugene,

when switch to PgDBE do not expect that your Code will perform well.

every ISAM Command must be "translate" to SQL-Statement. so a "loop"

Code: Select all

DO WHILE ! EOF()
   Do_Something() 
   SKIP
ENDDO

will use a lot of Time

under SQL you do not have "direct Access" to Data
when send a "new" SQL-Statement "old" Result-Set is not valid any more

so it is not "one line" change in DbeSys to use PgDBE

---

when ZIP a DBF you can "see" how much "Space" is in your DBF
so you can store much more Data when compress it

it is not much Work when have "Store" and "Replace" Network Function.

[Tom]

when switch to PgDBE do not expect that your Code will perform well.

That was true some years ago.

Expect that your code will perform very well. The guys had more than 10 years to optimize the engine for that, to find solutions, create new techniques (like data objects) and much more. The performance even locally is really good - and even with the kind of code Jimmy showed. And if the migration is done, the code can be optimized, and that offers the chance to improve speed by a high factor.

[Auge_Ohr]

hi Tom,

please have a look how Eugene Code look like about what i talk.
i agree that much have be done in PgDBE but still i can make a Wonder ...