Question Preprocessor directives

[incuboy]

Hi,

Is there a function that can be evaluated in preprocessor directive to check if database is connected? I'm using Progress 91.c in windows xp.

Something like this. &IF <not connected(dbname)> &then

Thanks

 

[RealHeavyDude]

To me your requirement does not make any sense and AFAIK there is no possibility to check a database connection using pre-processor directives. Maybe if you tell us more what's the requirement as to why you want to check the database connection with a pre-processor directive we could give a better answer.

Letting the compiler conditionally compile parts of the code depending on the fact whether a database is connected at compile time seems odd to me. That does not mean that you requirement is not reasonable - it's just that I don't understand it.

Heavy Regards, RealHeavyDude.

 

[incuboy]

The requirements is like this. I have database connected name db1 and during write trigger of the table1 under db1, i want to write that record also to different database lets say db2, so I wrote a table trigger for it. But the db2 is not connected yet. My code is like this:

TRIGGER PROCEDURE FOR WRITE OF PersonalInfoMst.
&IF < if not connected dbname > &THEN
CONNECT "-db payroll " NO-ERROR.
&ELSEIF <if connected >&THEN
CREATE payroll.employee.
ASSIGN
payroll.employee.emp_code = PersonalInfoMst.EmpCode

so my objective is sort of synchronization of data. If you have any advice to me it will be great because i'm still pondering what would be the best approach.

 

[RealHeavyDude]

I think there is a misunderstanding of what pre-processors do: They are resolved at compile time. If you use pre-processor directives like &IF &ELSEIF &ENDIF the code gets compiled conditionally, BUT, it does not get executed at compile time. AFAIK there is no way to connect a database during compilation of a procedure. At the time the procedure gets compiled the necessary databases must be connected in the first place.

I am still not 100% positive whether your problem needs to be solved at compile or at runtime. I guess it can be resolved at runtime and if that's the case you always execute the CONNECT statement at runtime whenever you detect that a database needs to be connected. The only restriction is that the procedure that connects the database may not reference any database objects - therefore you need separate the connect statement in its own procedure.

Does that make sense to you?

Heavy Regards, RealHeavyDude.

 

[incuboy]

"I think there is a misunderstanding of what pre-processors do: They are resolved at compile time. If you use pre-processor directives like &IF &ELSEIF &ENDIF the code gets compiled conditionally, BUT, it does not get executed at compile time."

Thanks heavy.

 

[Marian EDU]

a database trigger is hardly a place where one should attempt to connect to another database (in not connected already)... why do you want to hard-link the two systems, what if the other database is down, is your write trigger return an error and roll-back everything?

that's definitively the approach you want to take for data replication/synchronization... the source system should probably work just fine when the target is down for some reason, it will have to catch-up when the target system gets back online but the synchronization task is not something that should bother the application running on the source database.

just write some audit logs in a replication table in the source database, that can be done in replication triggers, and then have some batch processing do the real replication.

 

[incuboy]

a database trigger is hardly a place where one should attempt to connect to another database (in not connected already)... why do you want to hard-link the two systems, what if the other database is down, is your write trigger return an error and roll-back everything?

that's definitively the approach you want to take for data replication/synchronization... the source system should probably work just fine when the target is down for some reason, it will have to catch-up when the target system gets back online but the synchronization task is not something that should bother the application running on the source database.

just write some audit logs in a replication table in the source database, that can be done in replication triggers, and then have some batch processing do the real replication.

Thanks Marian for the advice. Could you give me samples or details on how to do this replication? If its ok with you? or just some articles that I can read about it.? Thanks in advance

 

[Marian EDU]

I don't have any samples that can be shared, I think Rares had some replication solution that used sonic mq as middle-layer... but if I remember correctly he had to take of the project from sourceforge as he was at the time an employee of PSC

But the base idea is to use the replication triggers (those aren't part of transaction) and save the replication info in an extra table. The table can be generic and have something like: source table name, operation (CUD), rowid or primary key info (if you need to support delete operation then you need the primary key so you can delete the same records on the target database).

Once you have that table filled you can run a cron-job each hour or so and have that parse the replication table and send that info to the target database... it can directly connect to it, call a web-service or appserver method that will handle the actual target database updates based on replication information it receives.

 

[incuboy]

Thanks a lot Marian, the problem is i am still learning the progress, and too bad the company that i'm working hasn't provided us enough training especially with kind of problem. So its gonna be long journey for me to accomplished this.
Great advice. Thanks again.

 

[RealHeavyDude]

Unfortunately there is no replication solution available on the market that supports the OpenEdge database. Event the one that Progress purchased once - anybody remember the name? They never got it to work with the OpenEdge database. In the end the sort of "retired" it for usage with the OpenEdge database. On the other hand not everybody understands the same when speaking about replication. Most of times I was confronted with the requirement it was a one way solution. Mostly it was a selected set of tables that need to be replicated to another database. Your best bet is a solution that Marian mentioned although you still need to roll your own. Me, I never had to implement such a thing myself therefore I can't share any code or documentation samples.

Heavy Regards, RealHeavyDude.

 

[incuboy]

thanks a lot guys.