ADS vs PG

[Tom]

You both forgot discussions on these topics:

And you missed to read those threads completely.

What's your mission? I don't understand it.

PGDBE works, and it works really well. We transformed a really f*cking huge application with it, and it works. Yes, the performance is not as good as with native SQL, but we saved YEARS of time. Time we don't have, and for all those guys in the same situation, PGDBE is an excellent solution. This is not a question of belief. If you want good results in short time (maybe because you have security issues with your file based db), this is a good way. If you are planning a big, critical application, use another way. Don't use Xbase++ in that case. Take a modern language. Build a web frontend and a server providing microservices and use a good, reliable, fast SQL server structure. This is not a question of belief also. There are only a handful of people on the planet who know Xbase++. New apps with Xbase++ don't have a future. There are millions of guys knowing Angular, React, Springboot and all the other stuff. Use that if you want to keep your business running longer than until 2027.

[rdonnay]

You both forgot discussions on these topics:

Those discussions were not intended to post reasons for my customer's project to fail.
They were intended to find support and solutions for the project to succeed.
And it worked!

I followed advice from those who have had success with PGDBE, and I also sent sample code to Alaska Software.
Alaska solved those problems by making 2 new updates to the PGDBE.
I also wrote some utility programs, in Xbase++, to streamline the upsizing process.

When I first started with Xbase++ in 1999, I didn't look for reasons why it could not be used to convert Clipper applications.
Instead, I wrote new sub-systems and utilities, entirely in Xbase++, to make it a productive tool for legacy Clipper applications.
Tom's very successful product started as a Clipper program, and he was able to leverage much of that legacy code.

[unixkd]

You both forgot discussions on these topics:

And you missed to read those threads completely.

What's your mission? I don't understand it.

PGDBE works, and it works really well. We transformed a really f*cking huge application with it, and it works. Yes, the performance is not as good as with native SQL, but we saved YEARS of time. Time we don't have, and for all those guys in the same situation, PGDBE is an excellent solution. This is not a question of belief. If you want good results in short time (maybe because you have security issues with your file based db), this is a good way. If you are planning a big, critical application, use another way. Don't use Xbase++ in that case. Take a modern language. Build a web frontend and a server providing microservices and use a good, reliable, fast SQL server structure. This is not a question of belief also. There are only a handful of people on the planet who know Xbase++. New apps with Xbase++ don't have a future. There are millions of guys knowing Angular, React, Springboot and all the other stuff. Use that if you want to keep your business running longer than until 2027.

Hi Tom

I don't want to agree with you 100 percent regarding the future of applications developed in xbase++. Surprisingly some people are still running legacy clipper applications that were compiled to xbase++ text mode. A lot of our clients never bother about the tools that we use but mainly interested in solutions that work for them. I don't believe that desktop applications will be going into extinction soon albinicio Xbase++.

By your assessment all desktop compilers/programming languages will become obsolate soon?

Finally let me thank everybody for your contributions you are all wonderful people.

Joe

[unixkd]

In addition to my post reply above I would like to know something.

Can an ERP application such as financial accounting system or hospital automation system be completely developed in stuff like React or JavaScript etc.

Sometimes ago a friend of mine who developed hospital management system said that one of his client wants a web version of the application. I suggested that he be cautious about being able to achieve the functionality of his current desktop application.

He went ahead to develop the web application in python using django web framework. Alas at the end of the day he couldn't achieve all the functionality of the desktop app. More importantly user interface on different devices became something else.

The client decided to continue with the desktop application but hosting his data on the cloud.

I had read a lot of articles about python I had thought it could do anything. Is there something I am not getting?

Have a wonderful weekend all.

Joe

[rdonnay]

I wrote an ERP system in Clipper back in the early 1990's.
It required so much custom configuration that I had to make the screens and other stuff fully data-driven.
One of the users was Annheiser-Busch.
When I was taken out to dinner I was required to drink Budweiser beer.
That was the last program I ever wrote that was mostly data-driven.
I learned that a better kind of language abstraction was needed and that led to eXpress++ and SGL.
I can't imagine an ERP app being written in Javascript.

[Tom]

I can't imagine an ERP app being written in Javascript.

Maybe this would be possible, but noone would do so. You may use JS to create parts of a frontend for an ERP system but other tools for the backend and the database.

[SlavkoDam]

Alaska upsizing process has nothing to do with the execution of an PGDBE application. So, improvements in upsizing has no influence to PGDBE itself, and Roger's test results are still valid and are very important measure for PGDBE performance. They cannot be disregarded.

Do you know that the famous ORACLE uses DOS batch files for installation of it's DBMS? This long installation process opens DOS command prompt and displays in it, DOS commands that are executed and their results.

When I started with Xbase++ I also faced with the same problem as Rodger, how to convert my Clipper applications to Xbase++. To achieve that task in a fast and easy way, I developed PowerWin library, entirely in Xbase++. It is a very productive tool for Clipper to true GUI Xbase++ migration, with minimum code changes. But, now days it is not enough. So, I also created other libraries for various tasks required by modern applications: SQL access, Internet protocols, Cryptography, Web design, Multi-CPU-threading. I have learned other languages to complete all this: C, C#, HTML/CSS, Javascript, PHP, and integrated them into Xbase++.

[Tom]

Nowadays, nobody would build an ERP system like it was done in the 90's. An ERP system should be build in a modular structure, highly scalable and on the user side completely platform independent. Tools like Kubernetes, Docker, Istio, Kafka are used for the microservices and their environment, Java, C# and others for the backend technologies. Whatever you add to your Xbase++ biotope, it's located on a lonely planet and completely lost in space.

This is true when you want to build something that lasts a while, created by a bigger team for a bigger company and/or market.

If you work for a company that can afford to work mainly with Windows monoliths, which may involve additional backend structure with web frontends, then you can also develop large parts of something like that with Xbase++. However, I can't imagine that there will be a generation change for Xbase++. The community is getting older and smaller, and there is no future for this in sight. You still can build highly integrated, genius applications with Xbase++ (we all do or did), but you will be the last person working on it.

[k-insis]

Can it be? Yes.

Should you? No.

Can an ERP application such as financial accounting system or hospital automation system be completely developed in stuff like React or JavaScript etc.

Joe

[k-insis]

There is absolutely nothing wrong for DBMS or any other software to be installed fully or party by script language, whether it is bash shell , powerShell or good old CMD batch. They all have purpose.

And what you saw was probably output of installer that invoked start Oracle specific services too that produced standard output before starting listeners/receivers. And that is quite normal something just about all server side products do once initial install is done. Was it cmd/bat or ps1 even bash it matters zilch as long as it work correctly.

Mind most of startup batches for server products consist of lengthy script that prepare environments and send some of output to std out and std err stream , syslog etc; it is just we do not see them as they run under system accounts.

And if you use "Windows Terminal", its default look is light gray characters on black background. But it can incorporate cmd, powershell, bash and all other shells in it to provide output.

Do you know that the famous ORACLE uses DOS batch files for installation of it's DBMS? This long installation process opens DOS command prompt and displays in it, DOS commands that are executed and their results.