Convert app to connect to postgres

[John Bester]

I have a client with a clipper program. My plan is to use harbour to convert the clipper program to a linux based application that uses Postgres instead of xBase. So I need to steps, step one will be a batch run to copy data into Postgres database and step 2 is to convert the application with the least amount of effort to use Postgres. Is it possible to to change the global database connection to Postgres without having to modify each individual clipper screen? If that is possible, then I can over time merge functional it into my erp system which is developed in Java. Also, are there some code examples I can look at to achieve this?

[Massimo Belgrano]

Quite easy migrating to linux where you need change your source bacause file name is case sensitive......FIle("TeSt.bat" not work if file is different
quite difficult migrating by revriting your source to postgress
Please examine prg in C:\harbour\contrib\hbpgsql\tests starting from dbf2pg.prg
This is a class who access to postress who require a rewriting
i rember a commercial rdd who can help http://www.otc.pl/download/default.aspx?l=2
this rdd your source can work without modification

My suggestion is maintain dbf for better realibilty if possible

2016-10-12 6:57 GMT+02:00 John Bester <jdar...@gmail.com>:

I have a client with a clipper program. My plan is to use harbour to convert the clipper program to a linux based application that uses Postgres instead of xBase. So I need to steps, step one will be a batch run to copy data into Postgres database and step 2 is to convert the application with the least amount of effort to use Postgres. Is it possible to to change the global database connection to Postgres without having to modify each individual clipper screen? If that is possible, then I can over time merge functional it into my erp system which is developed in Java. Also, are there some code examples I can look at to achieve this?

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-users+unsubscribe@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

[Tore Van Grembergen]

Dear John,

Based from experience in the past, i noticed that there are 3 other important elements to take into account.

Postgress is a SQL database. Consequently it is resultset driven.

a) Performance can only be reached when using it with SQL statements allowing for creating the smallest possible resultset to return to your application.

If your are using the tables from postgress as index sequential accessed tables, performance will be sloppy

b) with DBF files you can do incremental searches on the DBF file without having severe performance impacts.

Incremental searches can bring a SQL server down if datasets are becoming big.

c) It is very difficult to apply pessimistic locking on a SQL database. It is better to apply optimistic locking.

Kind regards

Tore

Unsubscribe: harbour-user...@googlegroups.com

Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

[Lorenzo Fiorini]

On Thu, Oct 13, 2016 at 6:29 AM, Tore Van Grembergen
<tor...@beerintime.com> wrote:

> Postgress is a SQL database. Consequently it is resultset driven.

> ...

> If your are using the tables from postgress as index sequential accessed
> tables, performance will be sloppy

> ...

> c) It is very difficult to apply pessimistic locking on a SQL database. It
> is better to apply optimistic locking.

I completely agree with Tore: SQL needs a different approach than ISAM's files.

Of course it depends to the complexity of your app: if you have few
small tables, you probably you can do a quick migration.
But if you have many users and large tables, you need to optimize your
inputs to have the most efficient query
strategy and retrieve only the set of data you need.
You need also to analyze the critical queries and create the right
indexes for the tables.

If you asked for Postgresql I assume you don't have a trivial
application, or it is a requirement for the project.

I'm working with Postgresql under Linux since years and I use it for
data warehouse and
Decision Support Systems where data analysis and data aggregation
functions are required.
But for multi user data enter and processing I still think that dbfs (
on Linux ) are a perfectly viable solution.

With more information we would be more useful.

best regards,
Lorenzo