Search results

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.

While implied by what Tom said, I think it is worth noting that dynamic code tends to be obscure while static code can be very clear in intent and purpose.

Declaring the variable in the enclosing program will allow you to use it in both places, but is sloppy programming. Much better to explicitly pass in any values needed by the outside program and to explicitly return any values needed later.

My first question is, why would you ever write code like that? If, for example, you consistently used bcust throughout, I am sure the compiler would complain.

This really should be a new thread.

You seem to be confusing variables. Nowhere in your code do you set the value of tog_demo except with the initial clause so of course it is still false. And, why input since there is no UI statement in your code.

It would be an interesting question to ask at Progress Communities as for the largest user count that anyone has seen.

If you are up for restructuring this code, one design idea you might consider is encapsulating temp-tables in their own class with access methods to operate on the temp-table. That isolates knowledge of the specific schema of the temp-table to that class and everything else merely knows about...

I meant your current effort and the actual HTML code so that we can see what you have constructed.

Perhaps if you attached an example of one of the e-mails someone knowledgeable about e-mails would be able to point at what was wrong.

I was very fond of working in X. Something about the whole experience which just blew Windows away ... especially with Windows back then. Even ChUI looked good. But, when PSC committed to Windows, not much choice.

Cringer ... it depends :) Back in Version 6, I did an implementation of Varnet on X-Windows which people thought was a GUI, just because the simple ChUI forms looked so much better on X-Windows. It amused a bunch of folks!

It seems to me that you have three distinct potential problems: 1. Composing a valid e-mail containing the desired image, regardless of how sent. 2. Interfacing with Outlook to make that e-mail appear to have been *sent* from the Outlook client. 3. Potentially dealing with any issues specific to...

Don't know about Outlook, but this sounds exactly like what happens for me with sending in plain text vs sending in HTML.

In particular, I might note that it is a frequent pattern in adding new functionality to an existing app to simply tag on a couple of fields to an existing table to support that new functionality. What is missed in doing this is an analysis for normalization. As a result, one often ends up...

But also the sort of refactoring which is likely to be amenable to automation. I'm not belittling the job, just pointing out that it is good practice to recognize when something is done wrong by current best practice and to consider what might be done to fix it properly instead of always doing...