DbRegisterClient() with PostGres

[rdonnay]

One of my eXpress++ users has been using my DC_DbNotify() function for years and has recently been adapting his application to PostGres. He claims that DC_DbNotify(), which is based on DbRegisterClient() does not trigger the notification with Postgres.

Is there anyone who is using DbRegisterClient() with Postgres?

There is nothing in the Xbase++ documentation that specifies it is not supported.

[Tom]

There is nothing in the Xbase++ documentation that specifies it is not supported.

And there is no PDR either. Did you ask Alaska?

We tried to use that a long time ago, but we stopped it.
Besides this and some issues with filters, the PGDBE works excellent.

[slobodan1949]

Dear Developers,
you who have been working in the Xbase++ postgreSQL database for a long time,
maybe you can help me with some good advice.

I am testing work with postgreSQL server (version 9.4.4 32 bit)
I use UPSIZE TABLE, obtained from DBFUPSIZE.EXE/DLL/LIB from DBF files.

UPSIZE TABLES are created by default in the 'public' schema in my 'test' database.
I need to have schemes in the 'test' database: '2023', '2024', '2025'...

Is it possible to create a UPSIZE TABLE in the '2023' scheme that will work
with PGDBE ISAM navigation ?

I wrote my own function which creates UPSIZE TABLE 'customers' in schema '2023'

But I can't solve the problem How command:
USE customers NEW SHARED ALIAS "cust"
can open table 'customers' in scheme '2023'

is this even possible?
If possible, is there an instruction about it somewhere?
I am unable to find answers to these questions on www.alaska-software.com.

[k-insis]

Found this one:

"Schema By default PostgresSQL use a public schema used for store information about the databases, tables, procedures. This schema by default is accessible by all users, so all users can see every tables structure or procedures "

Which is bummer


In pgODBC you can set search path for schema, but perhaps is there something same that can be sent to dacsession()
"pqopt={search_path=dbcevapi,dbpleskavica,public}"

This does need fixing.

Did they fix locked records persisting if client exe drops from network or is abnormally terminated? (I remember that beeing issue some year ago)?

Dear Developers,
you who have been working in the Xbase++ postgreSQL database for a long time,
maybe you can help me with some good advice.

I am testing work with postgreSQL server (version 9.4.4 32 bit)
I use UPSIZE TABLE, obtained from DBFUPSIZE.EXE/DLL/LIB from DBF files.

UPSIZE TABLES are created by default in the 'public' schema in my 'test' database.
I need to have schemes in the 'test' database: '2023', '2024', '2025'...

Is it possible to create a UPSIZE TABLE in the '2023' scheme that will work
with PGDBE ISAM navigation ?

I wrote my own function which creates UPSIZE TABLE 'customers' in schema '2023'

But I can't solve the problem How command:
USE customers NEW SHARED ALIAS "cust"
can open table 'customers' in scheme '2023'

is this even possible?
If possible, is there an instruction about it somewhere?
I am unable to find answers to these questions on www.alaska-software.com.

[Tom]

I am urgently waiting for support for different schemes. We need this in order to be able to map our multi-tenant-model because the route via different databases is too unwieldy. But when I see how little has been implemented in the last Xbase++ update, my hope is fading.

Here's what Alaska suggests to do this: https://ilx.alaska-software.com/index.p ... tgresql.3/

[slobodan1949]

Tom and K-insis,
Thank you for your answer.

Conclusion:
Alaska Xbase++ currently supports working with ISAM commands and functions only in UPSIZE TABLES that are in the 'public' schema.
ISAM commands and functions cannot be used in other schemas for now. This greatly complicates the development of business applications.

Example:
If the same business application keeps records of three different companies by year for a period of 5 years, the organization of the database should look like the given scheme:

Database 'Company 1'
Scheme '2021' Tables a1,a2,a3...
Scheme '2022' Tables a1,a2,a3...
Scheme '2023' Tables a1,a2,a3...
Scheme '2024' Tables a1,a2,a3...
Scheme '2025' Tables a1,a2,a3...

Database 'Company 2'
Scheme '2021' Tables a1,a2,a3...
Scheme '2022' Tables a1,a2,a3...
Scheme '2023' Tables a1,a2,a3...
Scheme '2024' Tables a1,a2,a3...
Scheme '2025' Tables a1,a2,a3...

Database 'Company 3'
Scheme '2021' Tables a1,a2,a3...
Scheme '2022' Tables a1,a2,a3...
Scheme '2023' Tables a1,a2,a3...
Scheme '2024' Tables a1,a2,a3...
Scheme '2025' Tables a1,a2,a3...

This can be done even now. But now it is not possible to work with ISAM UPSIZE TABLES in this system. Any other database organization system would be impractical and cumbersome and would disrupt the business logic of accounting records. I can only hope, as Tom says, that PGDBE.DLL will be supplemented with this functionality in a future version of Alaska Xbase++.

[Tom]

And there is not a single PDR concerning schemes in the Alaska knowledgebase.

To be a little more concrete. Upsized tables are always added to the "public" schema, and the PGDBE looks for tables only there. If schemes should be used to organize multi-tenancy, using the PGDBE and the upsize mechanism is not possible at the moment. But since several connections at one time are possible, organizing those tables in different databases is possible.

We have this situation:

Main
- table a
- table b

(Sub-)Company 1
- table c/1
- table d/1

(Sub-)Company 2
- table c/2
- table d/2

And so on. In a file-based world, this is easy with SET DEFAULT and SET PATH. The pathes are only needed when creating index files. This even works perfect with the ADS.

We intend to get this going with two database connections at one time. We set the "Main" connection to the default connection and check at "DbUseArea" if the table to-be-used is a main or a sub table. If it is a sub table, DbUseArea gets the "Sub" connection as the connection parameter.

The upsize process should work in the same manner. In this example, three upsizes are done. Maybe handling the databases gets a little more complicated, but this should work. It should work much better than waiting for schemes-support.

[slobodan1949]

Tom, thanks for the good idea.
I will test your system as soon as possible and get back to you with the result.

I also read the suggestion from:
https://ilx.alaska-software.com/index.p ... tgresql.3/
There they implicitly declare that it is not possible to incorporate ISAM navigation into PGDBE so that it works with several different schemes. They suggest coping in three ways. Your method is the fourth and it suits me best for now.

[Tom]

Slobodan,

my way is a variant of solution #1, switching databases. This is what I'm doing for the (sub-)companies, while one connection for shared tables always stays open. I think we will finish this approach lately in November.

[slobodan1949]

Regards Tom,
Your comment please