Search results

Try putting the code in code tags and adding a comment at the place of the problem line.

So, what is the problem line?

I would need to know more about the application before I could make any suggestions. Why don't you briefly describe sources, architecture, display intention, etc.

Unless there is a compelling reason to do this entirely in ABL, there are a number of commercial packages that do this sort of thing superbly.

Well, obviously, to compile fill.p you have to be connected to the other database. Have you tried putting a test in fill.p to verify that you are connected at run-time? FIND FIRST is almost certainly the wrong thing to be doing.

For starters, the include file should not be in two places ... that is asking for exactly this kind of problem. Re the connect, note that you cannot connect to a database and access the database in the same procedure. You need to connect to the database and then run another program and access...

This is likely to be a code page issue ... do you know what code page is the source of the characters?

Then, what does this mean? 2. live update of data whilde browsing

Say a bit about how you are controlling transaction scope. One of the reason for working against local tables or variables is so that there is no open transaction while you are doing the work and a very short transaction with no UI to commit the changes to the DB when done.

One might note that the default in ABL is share-lock and one has to explicitly say "no-lock".

I would think the first question would be whether or not there is a Progress installation on the machine somewhere. If that backup file was indeed created in May, then it seems likely. Also, who created that ... something else you could find in the log. Are they still around? Probably a lot...

I can't see how there is a chance of any problem. Why does this seem like an invitation to a real head scratcher!?

Quite aside from the vagaries of sort order and the like, it is almost certain that treating the first record of a group as special is a violation of good relational design. It is certainly reasonable to do a CAN-FIND test to determine whether or not there is one or more records matching...

I suppose the question now is, how long will it stay that way...

And only post to one forum with the same question.

Have you considered doing write-ups like this and posting them on wss.com so that you just need to drop the URL to respond thoroughly?

It is probably worth noting that, if the concern for performance is based on the existing unified database, it is quite likely that something else is the source of the performance issues, rather than it coming from a unified database.

Important in this evaluation is that it is highly likely that some transactions will span databases, necessitating two phase commit and the risk of one side of that transaction failing.

Perhaps all present know this, but I think it is worth saying explicitly ... some databases have table relationships expressly specified in the data structure of the database, but Progress does not. Some packages have naming conventions like those referred to above, sometimes complicated by a...

Notably, object-oriented constructs.