Paradox Community

Items in pnews.paradox-client_server

Subject:Re: Postgresql connection
Date:Mon, 4 Feb 2019 16:12:31 -0600
From:Mark Bannister <markRemove@THISinjection-moldings.com>
Newsgroups:pnews.paradox-client_server
Also, I'm playing with PostgreSQL 11 and using the serial datatype for 
key fields. Interactively on a form pdox will not update the display of 
the key field if a new records is inserted. Actually it does on the 
first insert but not subsequent ones.  I have to close and open the form 
to see the new records.
If I use a Tcursor I must enter data into some other field and unlock to 
get the key field to be updated.  I see your stored procedure call in 
your sample library.  was it an attempt to get around this?

The forceRefresh() call does not seem to do anything.

On 2/4/2019 8:28 AM, Mark Bannister wrote:
> 
> Excellent!
> I've been going through your library you shared a while (thank you very 
> much) and that all makes sense so far.
> So I still use PRIV directory as I do now, that's good.
> Currently I use sub-set data in PRIV for any form that is being edited. 
> I use a flag field to know if it is changed,deleted, etc.  I assume I 
> still need the flag field? Oh, just noticed you were doing it 
> immediately.  I think I like my way better.  You have a chance to undo 
> any edit but it is the same logic.  (Immediately is a bit cleaner and 
> less prone to issues though I would think.)
> I knew about pass-through SQL but I'm not sure how it works. Looks like 
> executeSQL is pass-through by default though from the help.
> 
> I've been slowly converting all queries to sql over the last year.  The 
> down side is that local sql is so quirky and simple that many queries 
> have to be broken into smaller ones in order to work.
> 
> Finally a real question, do you display data in forms directly from the 
> postgreSQL server (not sub-set data) and use the Pdox datamodel linking?
> 
> On 2/2/2019 6:27 PM, Tom Krieg wrote:
>> Yes, you still need the BDE. HOWEVER, if you design everything 
>> correctly, you can have a library that handles the calls to the SQL 
>> database, use pass-through SQL (i.e. don't use the pgSQL database in 
>> TCursors or the data model) and use SQL to extract subsets of the 
>> database to local (priv) tables for forms, reports etc etc. There is 
>> an easy way to display records (extracted from a SQL database to priv) 
>> in a tableframe and trap datapost or dataunlock, format an UPDATE 
>> query and send that to the database. So if users update a record in a 
>> TF, the update is immediately pushed to the pgSQL server. If you think 
>> it through carefully you will have a quick and efficient database that 
>> has none of the Paradox limitations, index problems or RI problems. 
>> Also, users do not need to have localshare=TRUE and don't need to 
>> share a NET file.
>>
>> Better still, if you put all your business logic, update logic and 
>> extract logic in functions, the database server handles those for you. 
>> Just use Paradox for display windows, the GUI and reports.
>>
>> Mark Bannister wrote on 3/02/2019 3:27 AM:
>>> So, I can't completely get rid of BDE then?  Everything still goes 
>>> through  BDE?
>>>
>>> On 2/1/2019 7:22 PM, Tom Krieg wrote:
>>>> If your BDE isn't configured to create ODBC aliases automatically, 
>>>> then yes.
>>>>
>>>> Mark Bannister wrote on 2/02/2019 9:39 AM:
>>>>> I'm confused.
>>>>> I've seen a few posts about using postgresql but am unclear about 
>>>>> the role of the BDE.
>>>>> I created a System ODBC connection to my postsgres server.
>>>>> Now do I have to create an alias in the BDE....?
>>>>> -- 
>>>>> Mark B
>>>
> 


Copyright © 2004 thedbcommunity.com