progress database aanspreken onder php

[Verwijderd]

Heeft iemand van jullie weleens gebruik gemaakt van een progress database link naar php?

Even voor de duidelijkheid overschakelen naar een andere database is geen optie.

Ik ben erg benieuwd hoe iemand dit voor elkaar gekregen heeft, welke documentatie ik bijvoorbeeld moet lezen etc. ...

Webspeed wil ik liever ook niet gebruiken.

Alvast bedankt

[Feyd-Rautha]

Heb je geen ODBC-drivers voor Progress ?

Anders kun je toch eenvoudig via ODBC_CONNECT() een 'dsn' aanspreken ?

[Verwijderd]

volgens zijn die er wel, ik zal er eens naar kijken.

[Verwijderd]

Hey, een progress db, is de 1e keer dat ik die tegenkom hierzo.
Ik heb zo niet direct een antwoord voor je, maar kijk 's op:
http://www.peg.com

(allerlei mail lists over progress, een must voor iedere progress ontwikkelaar/dba)

[Verwijderd]

Tnx voor de reply, ik moet toegeven dat ik er ook niet veel over weet. Ik moet op mijn stage nu onder progress gaan programmeren. Dat lukt op zich wel, maar de combinatie met php is wel een uitdaging. Mocht iemand nog tips hebben dan houd ik mij uiteraard aanbevolen.

[Verwijderd]

waarom geen webspeed? is in ieder geval veel sneller als een odbc naar de progress database, want je programmeert dan native.

[Verwijderd]

ps. waar loop je stage?

[Verwijderd]

hier de online docs:
http://psdn.progress.com/library/documentation/index.htm

[Verwijderd]

Ik loop stage bij een klein software huis in gelderland, ik weet niet of ik de naam mag noemen (van GoT en het bedrijf) en ik denk dat weet niet of er voldoende budget is voor webspeed, (rond de 10.000 euro) vandaar dat ik verder aan het kijken ben. Naar andere oplossingen.

[Verwijderd]

Er zijn voor progress zowel ODBC als JDBC drivers, ik zoek morgen wel ff het linkje.
Is het btw voor Progress 8 of voor Progress 9??

[ Voor 24% gewijzigd door Verwijderd op 03-02-2003 00:07 ]

[Verwijderd]

idd. de kosten kunnen snel oplopen. waarom ben je gebonden aan de progress-database, mysql is een meer voor de hand liggende keuze met php. wellicht kun je je strategie zo doen: post alle updates vanuit de progress-database naar de "online" webcontent database. deze kan dan gewoon mysql zijn. zo voorkom je dat je meer odbc en meer progress database licenties nodig hebt. en je hebt dan duidelijk "productie" en "test" gescheiden

[Gerco]

Webspeed vind ik persoonlijk wel lekker werken, maar als het per se met php moet is dat ook wel te doen via ODBC, al heb ik gehoord dat die ODBC drivers niet vooruit te BRANDEN zijn.

Het enige nadeel aan webspeed is tegelijk ook een voordeel, maar dat heb je altijd met progress, je kan niet gemakkelijk een veldje aan een tabel toevoegen oid, kun je gelijk de hele bliksemse boel weer opnieuw compilen...

PS.
Om nou Progress met MySQL te gaan vergelijken... wilt U in de toekomst niet meer zo vloeken aub?

[ Voor 12% gewijzigd door Gerco op 03-02-2003 00:39 ]

[Verwijderd]

Gerco schreef op 03 februari 2003 @ 00:39:
Webspeed vind ik persoonlijk wel lekker werken, maar als het per se met php moet is dat ook wel te doen via ODBC, al heb ik gehoord dat die ODBC drivers niet vooruit te BRANDEN zijn.

Het enige nadeel aan webspeed is tegelijk ook een voordeel, maar dat heb je altijd met progress, je kan niet gemakkelijk een veldje aan een tabel toevoegen oid, kun je gelijk de hele bliksemse boel weer opnieuw compilen...

PS.
Om nou Progress met MySQL te gaan vergelijken... wilt U in de toekomst niet meer zo vloeken aub?

Hmm. Waar heb je het over? Vergelijken? Waar is dat in deze thread gedaan? We all know progress rdbms rules...!

[Verwijderd]

Progress DBMS rules zeker, maar om nog ff op die gescheiden oplossing terug te komen...

Is het mogelijk om bijvoorbeeld de data tijdelijk op te slaan in een mysql table en dan bijvoorbeeld aan het eind van de dag over te gooien naar progress.

Controlled redundancy?

[Gerco]

Dat is een goede mogelijkheid, je moet in 1 of ander batch proces gemakkelijk de Progress database via ODBC aan kunnen spreken, MySQL op wat voor manier je dan ook wilt en de data zo overgooien. Als alternatief zou je ook nog met bestandjes kunnen werken (MySQL export, Progress import). Data overpompen is in ieder geval geen groot probleem.

Maar de andere kant op lijkt me logischer eigenlijk, als MySQL je "master" database wordt, waar heb je dan die Progress db nog voor nodig? Je zal duidelijk de dingen als triggers niet gebruiken, aangezien je je data om MySQL gaat invoeren.

De situatie Progress + applicatie en MySQL + website (read-only), lijkt mij een goede oplossing, tenzij je zowel via het web als via je applicatie data gaat invoeren, in zo'n geval zou ik toch voor webspeed kiezen.

[Theodoor]

Je kan ook de ODBC-drivers voor Progress van Openlink gebruiken ipv de standaard Merant ODBC-drivers. Die van Openlink zijn ook iets sneller. Ik heb thuis nog wel een linkje naar een website met een PHP API voor Progress. Je kan dan gewoon native Progress in PHP programmeren. Vanavond zal ik het eens opzoeken.

[Verwijderd]

Theodoor schreef op 03 February 2003 @ 16:35:
Je kan ook de ODBC-drivers voor Progress van Openlink gebruiken ipv de standaard Merant ODBC-drivers. Die van Openlink zijn ook iets sneller. Ik heb thuis nog wel een linkje naar een website met een PHP API voor Progress. Je kan dan gewoon native Progress in PHP programmeren. Vanavond zal ik het eens opzoeken.

Hm, lijkt me zeer interessant!! Zet je het linkje hier neer?

[Theodoor]

Check deze link: http://www.geocities.com/ncsoft/progress/index.htm

[Verwijderd]

Theodoor schreef op 04 February 2003 @ 20:10:
Check deze link: http://www.geocities.com/ncsoft/progress/index.htm

Ziet er zo op het eerste gezicht interessant uit! (ik lees het op het werk ff goed door allemaal).
Dat wordt kijken of ik progress op m''n debian bak aan de praat kan krijgen

[Atari Paul]

Ha, Progress m'n eerste stappen in professioneel programmeren (versie 6 dan).

Hmm, ik heb een paar jaar geleden een interface-database gebouwd in Progress om te kunnen koppelen met een kassa-applicatie. Dat was nog tussen Unix met Progress en Windows NT met .... (ik weet het echt niet meer).

De oplossing die we toen hebben toegepast was dat er op de kassa's een interface bestand werd aangemaakt wat we via ftp overtrokken naar de unix machines.
Van daaruit pollden we of er een nieuw bestand was vanuit onze interface applicatie.

Ook het omgekeerde proces pasten we toe. Dit gaat natuurlijk alleen werken als de data niet constant op to date hoeft te zijn.

[Theodoor]

maui71 > Laat me weten of je Progress onder Debian aan de praat krijgt. We hebben nu 2 Red Hat machines met Progress draaien, maar ik heb nog niet kunnen uittesten of Progress ook lekker onder Debian werkt, misschien willen we namelijk gaan overstappen naar Debian.
Laat me ook even weten of dat Procgi en proPHP class goed werken. Voor onze nieuwe website wilden we een koppeling maken tussen de website en onze Progress-database. Dit wilden we doen met PHP ipv Webspeed omdat het webdesignbedrijf veel PHP-kennis in huis heeft. Om diverse redenen hebben we hier toch van af gezien. Probleem is ook dat wij een hele beperkte licentie op Progress hebben (wel Webspeed, Progress RDBMS en Results, maar we mogen geen collectieve updates doen, kolommen aanmaken en laat staan tabellen aanmaken).

[ Voor 3% gewijzigd door Theodoor op 04-02-2003 23:09 ]

[Verwijderd]

Theodoor,

Progress schijnt goed te draaien onder debian.
De meeste problemen met linux hebben te maken met het hebben van de juiste java vm(ik weet niet zo snel welke).

over die licenties.. een beetje raar; als je de RDBMS hebt kun je ook altijd wel tabellen etc aanmaken, of heeft het te maken met de leverancier?

Procgi en en prophp maken gebruik van de CHUI-client.
Deze heeft een "per display" licence en telt "per display" mee voor de licenties.
kort gezegd:1 display is 1 ingelogde gebruiker.
zie webspeed - peg.com voor de vele "bijna" flamewars hierover

koely ,
ik zou gewoon een odbc driver gebruiken.. behalve als de query's&updates erg complex worden.

[ Voor 9% gewijzigd door Verwijderd op 05-02-2003 20:51 ]

[Verwijderd]

Verwijderd schreef op 05 February 2003 @ 20:50:
Theodoor,

Progress schijnt goed te draaien onder debian.
De meeste problemen met linux hebben te maken met het hebben van de juiste java vm(ik weet niet zo snel welke).

Da's goed nieuws. Dan kan je me morgen ff vertellen hoe precies te installeren
Of zit je dan nog bij PF ?

Anyway, dit weekend wil het gaan installen op mijn debian bak.

[Verwijderd]

PF? dat is toch niet die toko op de maastrichterstraat he?

[ Voor 2% gewijzigd door Verwijderd op 05-02-2003 21:07 . Reden: typo ]

[Verwijderd]

Verwijderd schreef op 05 februari 2003 @ 21:05:
PF? dat is toch niet die toto op de maastrichterstraat he?

Je gaat door voor de wasmachine !

[Verwijderd]

hmm. heb ik ook gewerkt.

[Verwijderd]

Verwijderd schreef op 05 februari 2003 @ 21:08:
hmm. heb ik ook gewerkt.

Dan ken ik je misschien wel, ik werk er sinds mei vorig jaar.
Heb eerst bij die toko in Amstenrade gewerkt

[Verwijderd]

Kennis van Ronald, trouwens?

[Verwijderd]

Verwijderd schreef op 05 februari 2003 @ 21:11:
Kennis van Ronald, trouwens?

Ronald J. jazeker

[Theodoor]

tc76,

Problemen met Java & Linux zijn mij bekend. Toen ik een nieuwe Red Hat server wilde installeren, probeerde ik Java VM versie 1.4.x te installeren (ik weet niet meer precies welke versie). Dit werkte flink ruk, dus toen heb ik toch maar weer de oude versie geinstalleerd (versie 1.3.x).
Het heeft volgens mij te maken met onze leverancier dat we geen collectieve updates (vanuit de Progress editor) mogen doen op onze database. De leverancier heeft wel wachtwoorden waarmee ze wel collectieve updates kunnen doen, ze gebruiken dit vooral om even snel 'iets' te fixen.

Binnenkort willen we een koppeling maken tussen onze Progress database en ons Account Management Systeem (voor netwerkauthenticatie). Dat Account Management Systeem is gebaseerd op Novell NDS eDirectory (LDAP). We willen een koppeling maken middels een JAVA-applicatie. Hier hebben we dus een JDBC-driver voor Progress nodig. Weten jullie of JDBC en Progress lekker (snel en stabiel) werkt? Is zo'n JDBC-driver nou heel erg duur?

[Gerco]

Mja, of er een JDBC driver is voor Progress weet ik niet, maar er is wel een JDBC->ODBC driver

Gebruikten we op de TUD voor Oracle ook, werkte alleen wel flink ruk.

[Theodoor]

Ik heb de JDBC-driver al gevonden. Het lijkt een ZIP-bestand te zijn in de java-directory in de DLC9-directory...

[Gerco]

Owjah ik zie het, is dat even aardig van Progress dat ze zomaar gratis en voor niets (absoluut niet Progress stijl, voor zover ik weet) een jdbc driver erbij leveren. Die zal hun eigen Java progsels wel nodig hebben dan

[ Voor 3% gewijzigd door Gerco op 06-02-2003 15:48 ]

[Theodoor]

Ja, ik verbaasde me er ook al heel erg over. Binnenkort maar eens wat gaan uitproberen

[Verwijderd]

Sorry dat ik zolang niet gereageert heb, ik heb het nu al een 2 weken werkend:

test opstelling:

PHPdev (win32) -> SCO open server.

Met de Merant 3.70 ODBC driver. Maar inderdaad gaat dit niet echt snel. Ik las een stukje hierboven dat het met de Openlink driver sneller gaat. Misschien dat ik dat ook nog even probeer. Maar het is toch een testopstelling. Hij moet later onder Linux gaan draaien.

Onder linux kan ik dan toch 'gewoon' de openlink driver installeren?

Nogmaals bedankt voor de informatie die ik hieruit gekregen heb.

ik heb ook nog een linkje:

http://www.progteg.com daar kun je ook best veel uithalen.

[Gerco]

Verwijderd schreef op 18 February 2003 @ 11:32:
Onder linux kan ik dan toch 'gewoon' de openlink driver installeren?

Zeg ik iets raars als ik zeg dat ik dacht dat ODBC een Windows-only iets was?

http://www.progteg.com daar kun je ook best veel uithalen.

Mijn turks is niet meer wat het geweest is, maar toch bedankt.

[Theodoor]

Gerco schreef op 18 February 2003 @ 12:18:
[...]

Zeg ik iets raars als ik zeg dat ik dacht dat ODBC een Windows-only iets was?

[...]

Mijn turks is niet meer wat het geweest is, maar toch bedankt.

Van de site is ook een Engelse versie.
Ik ben benieuwd naar de ervaringen van de combinatie PHP, OpenLink ODBC en Progress.

[Verwijderd]

nou, het loopt als een trein, lokaal welliswaar, met phpdev, ben nu bezig met de test versie om te zetten naar SCO openserver -> apache maar dat lukt niet echt.

ik krijg steeds:

dynamic linker: ./httpd: symbol not found: dlopen
Killed


als ik apache probeer te starten.

Maarja kom ik vast nog wel uit,


en inderdaad ik bedoel de engelse versie van de progteg site.

[ Voor 42% gewijzigd door Verwijderd op 21-02-2003 16:09 ]

[Verwijderd]

er schijnt ook iets voor UNIX/LINUX te zijn dat heb ik van www.progteg.gom

http://www.progteg.com/english/documents.html

[Verwijderd]

Bne @&^@ nog steeds op zoek naar de Progress/Linux cd

[Verwijderd]

Verwijderd schreef op 21 februari 2003 @ 16:08:
nou, het loopt als een trein, lokaal welliswaar, met phpdev, ben nu bezig met de test versie om te zetten naar SCO openserver -> apache maar dat lukt niet echt.

ik krijg steeds:

dynamic linker: ./httpd: symbol not found: dlopen
Killed


als ik apache probeer te starten.

Maarja kom ik vast nog wel uit,


en inderdaad ik bedoel de engelse versie van de progteg site.

Ik kom even terug op het bovenstaanden statement.

Ik kom er namelijk niet uit. Weet iemand wat het kan zijn?

Dit is de error:

dynamic linker: ./httpd: symbol not found: dlopen
Killed