Who is using PostGreSQL?

[Tom]

Jimmy doesn't like it. It's his right, he likes complex things.

Code: Select all

.T.

[rdonnay]

it seems that Jimmy doesn't like it. It's his right, he likes complex things.

Aha! Now I understand why he doesn't use eXpress++.

[Auge_Ohr]

hi Skiman,

Maybe the PGDBE is too easy.

i do also look "outside" Xbase++ World that´s all

the Question was : Who is using PostGreSQL?

i use PostgreSQL but not Alaska Way with PgDBE
there are many Ways to use PostGreSQL
you can also use "Pass-Through" Mode of Xbase++ v2.x without ISAM Style like some People do

---

i hope Alaska Way with PgDBE Concept will work for you so you need no other Solution

but there are other Solution to use PostgreSQL even when not have Xbase++ v2.x PRO
so why not tell it to Xbase++ who does not know about other Solution

---

a Way e.g. is to use PostgreSQL is ADO which work with SQL-Table, EXCEL-Sheet or DBF

you might have a look at
https://github.com/carles9000/wdo
xBase Code was made for Mod_harbour to use ADO with MySQL but include Soure for PostgreSQL and DBF
as i found out ActiveX OOP Syntax is 100% compatible so the Source should work under Xbase++

so have a look "inside" Download File wdo-master.zip\wdo-master\lib\wdo\rdbms_pg.prg

[skiman]

Hi Jimmy,

I already looked outside the xbase++ world, and I realised that with Xbase++ every problem can be solved. I started in 1986 with Clipper, and with Xbase++ I still have routines from that days working without any problem.

I already used the solution of Phil Ide to work with Postgres and used odbc to work with MySql. This was for small new projects and it was working without any problem.

I just checked that WDO() you mentioned and I see that it is using a sysntax that would be quite some work in a large application. alias->fieldname has to be changed to oTable:fieldget( 'fieldname'). Only this fact makes the use of PGDBE an obvious choice.

[Auge_Ohr]

hi Roger,

Time change fast ... must faster than in Xbase++

in "Cl*pper" Time i have use xBase Command like SKIP n
when switch to OOP i got use to o:DbSkip(n)

so what you think about a *.CH to "translate" xBase Command to OOP-Syntax

Code: Select all

#command  SKIP               =>  o:SQLSkip(1)
#command  SKIP <n>           =>  o:SQLSkip(<n>)

---

i´m not sure how "Cl*pper" Style Code will perform when "translate" by PgDBE

this Code Style is not good to "translate" into SQL Query

Code: Select all

   DO WHILE !EOF()
      IF EVAL(bBlock)
         AAdd( aArray, RecNo() )
      ENDIF
      SKIP
   ENDDO

this Code-Style is good to "translate" into SQL Query

Code: Select all

   DbEval( {|| AAdd( aArray, RecNo() ) } , ; 
            bFor, bWhile, nCount, , lRest  ) 

so it depend on Code Style how PgDBE will perform

---

i know you use ODBC.
i have work with ADO and Excel and found out that it can connect to "other" like MySQL, PostgreSQL or M$-SQL Server.

WDO() is based on ADO but it include Method which are used for ISAM Style.
so all the ingredients are there to build a own CLASS for multiple Data Format

you can use "Fast-Food" but i prefer "Gourmet-Food"

[rdonnay]

so what you think about a *.CH to "translate" xBase Command to OOP-Syntax

I do that in lots of places now.

I used to create and manipulate objects with *.CH commands before the DataObject() class was offered to us.

However, I refuse to overload or replace Xbase++ syntax in any way at all because this would make my code incompatible with existing Xbase++ code.

When I write a library, it must be able to integrate into any Xbase++ application without changing its behavior.

You may recall that there were some 3rd part libraries, back in the Clipper days, that replaced some Clipper functions.
That turned out to be a disaster for some developers.

Replacing SKIP with anything other than dbSkip() would confuse any programmer who had to maintain the software.

A better idea would be to create a new command syntax like I do in eXpress++. All commands start with DC* and all public functions start with DC_*.

SKIP and dbSkip() were designed to work with any work area, including ISAM and SQL cursors.
DC_DbSkip() was designed to work with additional features that I needed in a workarea that are not supported by Xbase++, like descending or ascending in a browse, or scoping with an array of record numbers.

An object-oriented based skipper would be unique to a specific class, therefore a command interface would be complex.

There is only one place that I break my rule - XDOT.EXE. For example, the dot prompt interpreter will translate SKIP to DC_DbSkip().
I needed to do this in the early days of Xbase++ before they supported advanced data management features like Scoping with indexes or arrays.
That's because it is designed as a utility program, not a library of functions and commands.