bb.donnay-software.com

Hello everybody.
I'm really glad this topic happened.
It is obvious that it is imperative to migrate the Dbfs to a more secure and robust Table management system.
I have some tests with PostGree SQL 9.5.
I have a remote server that I use to activate, renew and manage software licenses that I install on clients.
It works very fast and accurate.
I would like to state here that all the development that Roger can do in eXpress will be very important so that we can use it with PostGree. If I can help with anything, I'll be available.
Regards.

Hi, Jimmy.

so Tom must have "workaround" all those "O"pen Problems with PgDBE

Your list contains all closed PDRs and all open PDRs with usable (and, in most cases, simple) workarounds. Only a few are open, and as far as I know, not one of those is critcal. This one (the newest):
just needs a refresh of the scope, which is not a big thing. I was the one who reported this behaviour, and they are working on it; I assume it will be fixed in the next update. The more people work with the PGDBE, the more stable and reliable it will get. But most of the work is already done.

But this is not a race and not a competition. The PGDBE is one of the available ways to move to SQL. There are others, everybody knows, and all have advantages and disadvantages. But Roger asked: Who is using the PGDBE-concept? And I do (and I'm not the only one). It works excellent. It may not be finished, it may have bugs, but, hey, this is damned software. Software is intended to have bugs and to never be finished. Our bug reporting system has more items than the PDR system from Alaska, and some dozend of those bugs are still not fixed. But most of this is something like: If you click here and there at the same time and interrupt power than and the moon is full, one pixel in the middle of the screen will turn red. We will fix that, if the important stuff is done.

You found your way to deal with SQL. Go ahead, share your experiences. But please stop trying to sell your way as the best, as the only good one. This is not true. And: Nobody cares.

SET SOAPBOX ON

Success in software development depends, IMHO, on having a clear, long-term vision for a better programming universe.
It's not about making a lot of money.

In the early days of Xbase++, many 3rd party developers didn't take the time to get to know Steffen Pirsig and they didn't understand his technology-driven approach over a market-driven approach. I understood it very well, because I saw the results of market-driven software development. It was the death of many great ideas and products.

The computer, Tesla EV, SpaceX, Amazon, iPhone, mRNA and many other grand ideas were all developed with a vision of a better universe for human beings. All of them took intelligence, courage, persistence and the competence of great leadership. Money was not the driving force.

I believe in the team at Alaska Software because they persist in their long-term vision of a better universe for our small community of Xbase++ and Clipper programmers, and, hopefully, have learned to drop bad ideas such as Polar Fox.

SET SOAPBOX OFF

I have decided to invest myself in really getting to know PostGreSQL. I just downloaded and installed version 12 onto a server and will put many new features in my SqlQuery tool to make it easier for Xbase++ users. For example, I will add a feature that will build *.upsize files, automatically, from an ADS data-dictionary and launch the DBFUpsize tool. It should automatically handle decryption and reencryption of tables that have been migrated. This is just one idea. I anticipate that many more productivity features will be required to ensure a smooth and seamless transition.

I also intend to persist in improving SqlQuery as a consistent query tool for all SQL servers. It has been tested with ADS, MySQL, PostGreSQL, SQL Server, Microsoft Access, and other ODBC interfaces.

I will be creating a new PostGreSQL forum on this board so we can help each other in getting started and learning how to hybridize our application as we did when transitioning from text-based to GUI.

hi,

why you want to use SQL ?
most xBase User will say : to break 2 GB DBF Limit.

but are you sure that it work with 32 Bit PgDBE ISAM App ?

---

as DBF can not be > 2 GB i guess nobody have "test" a Table > 4 GB with PgDBE ?

PgDBE ISAM will create "intermal" FIELD(s) for "Index" in SQL Table

let say i have 10 FIELD(s) Type "C", 100
also have 5 Index with IndexKey ( FIELD_1 + FIELD_X )
so Index take 1/2 of Space or REDUCE Space of possible Data to 50% !

---

the "Competition" is to find out LIMIT to use PostgreSQL with Xbase++

the Idea of PgDBE is good but Concept with "internal" FIELD(s) with IndexKey() make a lot of Overhead.

p.s. look "outside" Xbase++ World how "other" RDD ( = DBE) work to simulate ISAM Style

Bullshit.

Why SQL?

To ensure your data is much safer than it is when using a file based database system. To establish an access structure. To improve speed. To have more control about the data. To ensure data integrity. To have the chance to improve the code quality, get more compact code. To move service structures to a server. To open up the database for direct access from other systems (which works perfect even with PG/ISAM). To use modern backup structures. To protect data. To compete on the market. To increase the value of the software.

Your view is just your small my-own-world-view. Go ahead, share your experiences, but stop complaining about something you're just not interested in. Thanks in advance.

Tom,

i don´t think Eugene want to change for Security ... he want to work with "more Data" than 2 GB.

You are "Master of Words" but i need Sample to "show" so everybody can reproduce it.

---

you can (f)create a File and (f)Write > 4 GB (2^32) and even (f)read
but FSeek() will return 0 when > 4 GB
how does 32 Bit PgDBE work

if your Business do not touch that 32 Bit Limit it will work with PgDBE
but there are People which work with much more Data as in "small xBase" World

This is not the thread about Eugene's problem with limited table sizes. There might be other solutions for him; PGDBE might be one. The topic of this thread is: Is the PGDBE useable for what it is intended for? You can't say nothing about this. You keep repeating the same shit again and again. You are wasting time and resources and nerves.

Tom wrote: ↑Fri Jan 21, 2022 3:01 am This is not the thread about Eugene's problem with limited table sizes. There might be other solutions for him; PGDBE might be one. The topic of this thread is: Is the PGDBE useable for what it is intended for? You can't say nothing about this. You keep repeating the same shit again and again. You are wasting time and resources and nerves.

Maybe the PGDBE is too easy. If it is not a complex solution, with the use of exotic tools, it seems that Jimmy doesn't like it. It's his right, he likes complex things. I remember a presentation of him during an event in Germany, which was from a technical view at a high level. However I think none of the developers who attended the presentation ever used it.

As a real software company, we need to To compete on the market as you said before. Users are interested in solutions which will help them in their daily work. Users don't care about the database that is used if their data is safe and they don't have complaints about speed.

In a lot of cases moving to SQL is not for the users, but for the managers who don't use the system. It just sounds better for them.

And yes, SQL is simply a better solution in terms of database integrity and security according to dbf files. So time to go forward and to see what PGDBE can offer. And thanks for the experience you shared, otherwise I propably would never be interested in it.