From: Robert on
On Fri, 25 Jul 2008 14:03:27 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz>
wrote:

>I've been looking at set operations as replacement for cursor based ones but
>I simply haven't had time to really get my head round it yet.
>
>How would you insert multiple records, then?

In Oracle, like this:

employee-ID occurs 1000 pic 9(09).
employee-name occurs 1000 pic x(30).
employee-salary occurs 1000 pic 9(9)v9(2);
row-count pic 9(4).

EXEC SQL FOR :row-count
INSERT INTO EMPLOYEEES ( ID, NAME, SALARY)
VALUES (:employee-ID, :employee-name, :employee-salary);

You cannot say 01 employee occurs 1000. 05 ID pic 9(09). ...
Each variable must be an array.
From: Anonymous on
In article <r79i84dhrco810pud78m84uucod1kmiqr7(a)4ax.com>,
Robert <no(a)e.mail> wrote:
>On Thu, 24 Jul 2008 12:37:33 -0700 (PDT), softWare design
><sabraham(a)baxglobal.com> wrote:
>
>>On Jul 24, 11:17�am, Howard Brazee <how...(a)brazee.net> wrote:
>>>
>>> This leads me to ask:
>>> 1. � What do you man by columns in an index file?
>>> 2. � What is the relationship between being open or closed and being
>>> able to add columns?
>>>
>>
>>
>>Suppose I want to change my data model by adding a column
>>to a table (field to a file record). With a relational database
>>I add the column and the job is done. Any program that needs
>>to work with that new column can on-the-fly, and any existing
>>programs that do not care about the change stays untouched.
>
>Alternatively, leave the original file unchanged and put the new
>column(s) in a another
>file. Programs interested in the new data will have to join the two
>files, while old
>programs need not be changed.

Decades on back I was taught a part of the Zen of Programming:

'What does a programmer do when given an 80-character record?'

'Reserve ten characters for future use.'

It used to be a common tecnique; a chunk of space - in the example above
at least enough to contain a decent-sized key to an indexed dataset - was
left as FILLER.

When new uses were found the FILLER decreased... and when the FILLER
finally disappeared it was the job of anyone who dealt with programs that
touched the file (or who dealt with the programmers who dealt with the
programs) to say 'The system has reached its design limits and budget must
be allocated to compare former needs with current ones so that a plan
might be developed which results in a better meeting of our changed
requirements. A newly-married couple or a family with two snall children
can fit comfortably into a compact car; as they age or family size
increases a different vehicle is needed for comfort... this is a
predictable result of growth.'

DD

From: Anonymous on
In article <6esodiF8oskkU1(a)mid.individual.net>,
Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>
>
>"HeyBub" <heybub(a)NOSPAMgmail.com> wrote in message
>news:8LednfeyoZGWLBXVnZ2dnUVZ_vninZ2d(a)earthlink.com...
>> Pete Dashwood wrote:
>>>
>>> (Don't take HeyBub's post seriously... he is winding you up... :-))
>>>
>>
>> You think?
>
>Yep :-)
>
>I understand there is an element of seriousness in what you're saying, but
>if you go down that route it ends in tears.
>
>IT does NOT own the data and IT should not have exclusive access to it.

Mr Dashwood, this needs clarification. There are, I believe, several
kinds of access.

Who do you believe to have the responsibility for insuring the accuracy of
data used for a company's vital (including, but not limited to, strategic,
tactical, structural and legal-compliance) data?

I would argue that those who are responsible for this insuring data
integrity have exclusive authority to limit INSERT/UPDATE access.
READ/BROWSE access is another matter, entire,

DD

From: Pete Dashwood on


<docdwarf(a)panix.com> wrote in message news:g6c6hj$srk$1(a)reader1.panix.com...
> In article <6esodiF8oskkU1(a)mid.individual.net>,
> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>>
>>
>>"HeyBub" <heybub(a)NOSPAMgmail.com> wrote in message
>>news:8LednfeyoZGWLBXVnZ2dnUVZ_vninZ2d(a)earthlink.com...
>>> Pete Dashwood wrote:
>>>>
>>>> (Don't take HeyBub's post seriously... he is winding you up... :-))
>>>>
>>>
>>> You think?
>>
>>Yep :-)
>>
>>I understand there is an element of seriousness in what you're saying, but
>>if you go down that route it ends in tears.
>>
>>IT does NOT own the data and IT should not have exclusive access to it.
>
> Mr Dashwood, this needs clarification. There are, I believe, several
> kinds of access.
>
> Who do you believe to have the responsibility for insuring the accuracy of
> data used for a company's vital (including, but not limited to, strategic,
> tactical, structural and legal-compliance) data?

Er... that would be the corporate insurers... Phoenix Life, maybe...? :-)

If you mean ensuring the accuracy of data, then whoever is manipulating it
takes responsibility for the manipulations they apply.

There is corporate backbone data administered by the IT department and there
is local data freely circulated within and around departments. IT have a
right to require that certain data feeds are provided to them to support the
corporate data asset, but the owners of that data have a right to access it
too.

>
> I would argue that those who are responsible for this insuring data
> integrity have exclusive authority to limit INSERT/UPDATE access.

Yes, you could argue that anyone dealing with the corporate data backbone
would not be allowed to apply updates to it directly, and all such updates
would be subject to scrutiny before (and after) being applied. That would be
covered by process and procedure.

You can have crazy situations where a department provides the required data
and then realises there are some errors in it. They are not allowed to
correct them until the next cycle which could be a week away, or they have
to request IT to correct them and there is paperwork involved so they just
leave it. A system that allows people with the proper authorization to
manipulate data which they originated, given proper checks and balances, is
far better than ONLY IT personnel being allowed to do it. (IT are from
infallible, anyway...)


> READ/BROWSE access is another matter, entire,
>

Sure. It comes down to people having the right access permissions so they
can maintain their own data and be responsible for it.

Pete.
--
"I used to write COBOL...now I can do anything."


From: Pete Dashwood on


"Robert" <no(a)e.mail> wrote in message
news:cffi84hdasss50ka2g3e00jarq6sppf2l1(a)4ax.com...
> On Fri, 25 Jul 2008 14:03:27 +1200, "Pete Dashwood"
> <dashwood(a)removethis.enternet.co.nz>
> wrote:
>
>>I've been looking at set operations as replacement for cursor based ones
>>but
>>I simply haven't had time to really get my head round it yet.
>>
>>How would you insert multiple records, then?
>
> In Oracle, like this:
>
> employee-ID occurs 1000 pic 9(09).
> employee-name occurs 1000 pic x(30).
> employee-salary occurs 1000 pic 9(9)v9(2);
> row-count pic 9(4).
>
> EXEC SQL FOR :row-count
> INSERT INTO EMPLOYEEES ( ID, NAME, SALARY)
> VALUES (:employee-ID, :employee-name, :employee-salary);
>
> You cannot say 01 employee occurs 1000. 05 ID pic 9(09). ...
> Each variable must be an array.

Thanks for that.

Amazing coincidence. I was today just looking at doing that (not for insert)
so I could get a series of rows from an attached table with a single join on
the base table. I haven't actually tried it yet but both MS ACCESS and SQL
Server are supposed to support it. I'll let you know if it succeeds.

In the past I have always defined Host Variables at an 01 level (because
that works for nearly ANY RDBMS) and have never used an occurs clause on a
sub level. According to the Fujitsu docs this is valid.

Pete.
--
"I used to write COBOL...now I can do anything."