hey

Casper

ProgressTalk.com Moderator
Staff member
lol! beschuitfluiter :lol:
Now that are real tricks :awink:

welcome​
 

Casper

ProgressTalk.com Moderator
Staff member
Had to google for this one :)
His name 'beschuitfluiter' in english is something like ruskwhistler. If you have your mouth full with rusk and still can whistle, then you are really good :).
 

BlubBlub

New Member
wow 6.3, that's old ;-)
Migrating to.....?

Integrating is more the thing - mysql on one side with read and writes to progress.

Our customer wants to keep his ancient stuff (and migrating the full thing would be more work than needed).
 

Casper

ProgressTalk.com Moderator
Staff member
They didn't consider upgrading Progress? In most cases it's just a simple recompile. That would make your work much easier. SQL and Progress 6.3 isn't a very good combination.....
 

BlubBlub

New Member
They didn't consider upgrading Progress? In most cases it's just a simple recompile. That would make your work much easier. SQL and Progress 6.3 isn't a very good combination.....

I was allready behind the part of using SQL on the Progress-side *g*

Learning 4GL now() while using it... it's a nice language anyway :)

Thinking: call procedure, catch output, parse output to sql, insert into table on mysql (and from there on we work further) and back.

There are bigger issues than that :)

Now working on: procedure to dump some table-data into something csv/xml like thingie to have it parsable.
 

joey.jeremiah

ProgressTalk Moderator
Staff member
we did a few progress to mysql real-time (near real-time :)) replication projects. mostly for reporting.

private message me if you'd like to hear more. i'll be happy to talk to you.

6.3 is a stretch (i believe 6.3 was released in 1992 or 1993) but i like a challenge :)
 

Casper

ProgressTalk.com Moderator
Staff member
Now working on: procedure to dump some table-data into something csv/xml like thingie to have it parsable.

CSV is the easiest:

Code:
&scoped-define TABLE-NAME <nameofyourtable>
output to <pathtooutputdir>/<filename>.
for each {&TABLE-NAME}:
     export delimiter ';' {&TABLE-NAME}.
end.
 
output close.

Casper.
 

joey.jeremiah

ProgressTalk Moderator
Staff member
hi Casper,

i may be digressing ...

the progress sql engine had some very serious growing pains. we all remember some of the flames.

looks like you have a very rich experience in that area. from your experience how ready is it nowadays (the progress sql engine) ? are we there yet ?

some important features that it is still missing ? especially in comparison to sql server (incase you are or have used it) and especially for reporting and bi use.

and any other pains like the sql width etc. ?
 

Casper

ProgressTalk.com Moderator
Staff member
Well, not so very rich experience. I'm more like forced somewhat to make sure SQL on Progress (oops OpenEdge) database works, since lots of our customers use reporting tools on our database.

Well, lets start with the positive news:
In OpenEdge 10.1B almost all our problems we had with version 9 have disappeared. We experienced lots of problems with hanging _sqlsrv2 processes for instance.
Furhermore all our customers experienced a very significant performance increase with all their queries.

So regarding these things everything has become lots and lots better.

There are still strange things happening with SQL:

For instance if you have a query on 2 tables with a nice indexed join. Sometimes extending the where clause with some OR construction on some unindexed fields in the second table causes the join to disappear when you look at the query plan. So you must be very carefull how the query is written. Update all column statistics can overcome this problem.

Another example is that if you have a bad performing query then it sometimes just stops executing, without any error the proces dies. (I hate this word....sometimes... :)).

There are 2 important things to do:
  • run dbtool on a daily basis
  • run update statistics on a regular basis
If we use nice indexed joins and group-by then everything works pretty fast.

Are we there yet?
Well If I said we where there I probably get a big argument with our friends BCM and RHI so I wont say that.
(select * from ... where 1 <> 1 still takes ages on a big table :eek:)

Regarding to the features missing, I hope RHI and BCM have something to say about that, they have more knowledge of SQL then I have.

But for the purpose we use it it for (reporting) it is mighty fast and depending on the type of information gathered it can outperform ABL.

Oh and another nice feature I think is being able to connect to more then 1 database at the same time (yes I know only one can be updated, no distributed transactios).

Casper.
 

BlubBlub

New Member
CSV is the easiest:

Code:
&scoped-define TABLE-NAME <nameofyourtable>
output to <pathtooutputdir>/<filename>.
for each {&TABLE-NAME}:
     export delimiter ';' {&TABLE-NAME}.
end.
 
output close.

Casper.


Export was the thing I needed - I was allready thinking how I could remove the field-names from my outputfile.

Tnx
 
Top