Re: 4gl development question

Neil wrote: > The way our 4gl application has evolved we make use of system calls to > execute other programs rather than linking in that functionality > directly to the calling program. > > For example this leads to the following type of code > > program1: begin work > ....... > commit work > run "program2" > begin work > ....... > commit work > > with the transactions being commited prior to the call to avoid locking > difficulties. > > This has worked (made to work) but has never been ideal as we should > really have a single transaction. > > Now we have a requirement to keep the work in a single transaction I was > wondering if there is an elegant way of having two 4gl programs > effectively share the same connection (and transaction). My fallback is > to rework the code and link in the appropriate modules but this will > lead to bigger executables, more maintenance and will take some time to > achieve ... I'd rather not do this. > Sigh. Being able to kludge something to make it work and having a maintainable solution are two different things. As someone pointed out, a better solution would be to make your 4gl in to shared libraries and then link the different functions in to your app. Think in terms of functional requirements. Why is your work spread in to two different programs? Remember, to think about what you're designing. Just because you can make it work, doesn't mean its a good idea. Like putting a V8 racing engine in a Yugo. It can be done, but not a good idea. But hey, what do I know? ;-)

On Sat, 26 Feb 2005 19:23:44 -0600, nobody <nobody@devnull.org> wrote: > >Like putting a V8 racing engine in a Yugo. It can be done, but not a >good idea. > >But hey, what do I know? ;-) Put that Yugo engine in a so-called SUV - oh, sorry they're already doing that.