OPEN all files

#21

Kind friends and respected colleagues : I've found both Common and
Named Common to be quite useful - with a healthy dose of professional
caution. I'm not going to deprive myself of their benefits, nor of
the benefits of other tools, just because someone in the future might
not understand them. I'm of the opinion that features shouldn't be
avoided through fear that someday they will be misused. If that's the
way we're going to live then we should stop working with software
altogether.

The greater-than sign can be mis-used if someone adds an equal sign
right next to it - but don't remove the greater-than sign.

Someone may accidentally Delete an order when the value goes to zero
rather than flagging the record as paid - but don't take my Delete
statement away.

Music and video games don't corrupt kids.

Guns don't shoot themselves.

Let's stop blaming the tools and easy targets and start putting the
blame where it really rests:
- Stupid/uninformed programmers
- Stupid/misguided kids
- Stupid/stupid people with guns

And we don't just survive in this business because we write perfect
code. We're human and we can make mistakes. So let's use the tools,
and if we screw up, load a backup, fix the problem, and move on.
That's what they pay us for.
But don't avoid the tools because that might happen some day.

Ahem. Off the soapbox. Thanks for your time.
T

#22

The only way that a system can be made fool proof is to fire all of the
fools.
BobJ

"Dale" <dbenedict99 (AT) gmail (DOT) com> wrote

Quote:

On Feb 14, 7:15 pm, Kevin Powick <kpow... (AT) gmail (DOT) com> wrote:
On Feb 14, 5:35 pm, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:

From what you are saying, the problem lies not with the feature, but
with the people that developed it.

Isn't this usually the case? Many languages have features, such as
global variables, but using them is widely considered poor programming
practice. Persistence of common variables across accounts, in D3
anyway, leads to even greater risks.

We have always used COMMON in our business software, and use Global
Common within Visage

Yes, but you have been around since the beginning of your software
development, so I imagine you have a solid understanding of how Common
is used throughout your systems. Many of us are not so lucky.

Since Pick was geared towards "business people" being able to build
their own information systems with little background or skill in
computer programming, that's exactly what you got a lot of the time.

I found an old CDP thread from 2001, that I started, regarding the use
of common blocks. It seems people still feel the way they did 9 years
ago.

http://groups.google.com/group/comp....se_frm/thread/...

There are the names of some people that I miss around here in that
thread.

--
Kevin Powick

Ross,

There is a vast difference between the COMMON and named COMMON, at
least in D3. I personally try to stay away from the named common, as
the block of variables remain intact when logging from one account to
another. The regular common only exists within the main program and
within its subroutines.

The regular COMMON statement I think is a good thing. The NAMED
COMMON is a disaster waiting to happen. Should something go sideways
when logging from one account to another and the named common does not
get clear and reset properly, one could be writing/deleting (CRUD) to/
from files that should not open.

Dale

#23

On Feb 16, 2:46*am, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

Quote:

*I'm not going to deprive myself of their benefits, nor of
the benefits of other tools, just because someone in the future might
not understand them. *

Understanding them is not the point. That they can easily lead to
insidious bugs that are difficult to track down is the real issue.

[remaining drivel and ridiculous analogies snipped]

--
Kevin Powick

#24

Dale,

I'm well aware of the difference between named & "regular" common -
and this doesn't reduce or diminish their usefulness in any way. We
use both, though our basic application design is probably different to
whjat many people have, because our users simply don't log from one
account to another ... or if they do it is under program control, so
"the right things happen".

Has served us well for over 25 years .... and if you were really
"scared" you could probably esily figure out ways to overcome the
issue --> you seem well aware of what the issues are, and it isn't
exactly rocket surgery

If you have one main "menu" or "driver" PROGRAM (don't understand how
some people can justify NOT having their own menu processor) which
simply checks the "current" account against the one stored in global
common

Cheers

On Feb 16, 5:42*pm, Dale <dbenedic... (AT) gmail (DOT) com> wrote:

Quote:

On Feb 14, 7:15*pm, Kevin Powick <kpow... (AT) gmail (DOT) com> wrote:

On Feb 14, 5:35*pm, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:

From what you are saying, the problem lies not with the feature, but
with the people that developed it.

Isn't this usually the case? *Many languages have features, such as
global variables, but using them is widely considered poor programming
practice. *Persistence of common variables across accounts, in D3
anyway, leads to even greater risks.

We have always used COMMON in our business software, and use Global
Common within Visage

Yes, but you have been around since the beginning of your software
development, so I imagine you have a solid understanding of how Common
is used throughout your systems. *Many of us are not so lucky.

Since Pick was geared towards "business people" being able to build
their own information systems with little background or skill in
computer programming, that's exactly what you got a lot of the time.

I found an old CDP thread from 2001, that I started, regarding the use
of common blocks. *It seems people still feel the way they did 9 years
ago.

http://groups.google.com/group/comp....se_frm/thread/...

There are the names of some people that I miss around here in that
thread.

--
Kevin Powick

Ross,

There is a vast difference between the COMMON and named COMMON, at
least in D3. *I personally try to stay away from the named common, as
the block of variables remain intact when logging from one account to
another. *The regular common only exists within the main program and
within its subroutines.

The regular COMMON statement I think is a good thing. *The NAMED
COMMON is a disaster waiting to happen. *Should something go sideways
when logging from one account to another and the named common does not
get clear and reset properly, one could be writing/deleting (CRUD) to/
from files that should not open.

Dale- Hide quoted text -

- Show quoted text -

#25

On Feb 16, 10:20*pm, "RJ" <nob... (AT) nowhere (DOT) com> wrote:

Quote:

The only way that a system can be made fool proof is to fire all of the
fools.
BobJ

Now what is the use of a shell company with no employees?

No, I say keep them there, otherwise we will ALL be out of a job!

#26

To: Ross Ferris
Ross wrote:

Quote:

From Newsgroup: comp.databases.pick

On Feb 16, 10:20pm, "RJ" <nob... (AT) nowhere (DOT) com> wrote:
The only way that a system can be made fool proof is to fire all of the
fools.
BobJ

Now what is the use of a shell company with no employees?

They become patent trolls.

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
--- Synchronet 3.15a-Win32 NewsLink 1.91
The Retro Archive - telnet://bbs.retroarchive.org