I'm a PICK programmer. Just wondering how marketable PROC programming
knowledge is....
I'm a PICK programmer. Just wondering how marketable PROC programming
knowledge is....
You could always become a PROCtologist.Quote:>I'm a PICK programmer. Just wondering how marketable PROC programming
>knowledge is....
Sorry, couldn't resist.
Jim Harger
Slightly more marketable than RPL, methinks, ie, not at all...Quote:>I'm a PICK programmer. Just wondering how marketable PROC programming
>knowledge is....
By itself, not much, but if your other Pick/MV skills are strong, it could
prove useful if you find yourself working on a legacy system which uses a lot
of cryptic procs, especially if they update files.
Regards,
Charlie
>I'm a PICK programmer. Just wondering how marketable PROC programming
>knowledge is....
I think you should know something about Proc. There are plenty of systems out
there that rely heavily on procs, so unless you are only developing new
software, you will have to deal with them.
If you create anything new using Proc though, you are doing a disservice to
those who will have to figure out your work at some point in the future.
I would add though, that the "menu processor" that was supposed to replace Proc
for character based menus, is kind of crummy. I suppose that Proc is still
useful for that kind of menu (we don't use it), as you can make changes to it
without compiling, and if a user "bombs" because of a change to a menu Proc, it
is usually a fairly benign problem. The macro processor, on the other hand, is
extremely useful for "one off" reports and routines, putting processes to
sleep, etc..
Robert Herbin
>By itself, not much, but if your other Pick/MV skills are strong, it could
>prove useful if you find yourself working on a legacy system which uses a lot
>of cryptic procs, especially if they update files.
>Regards,
>Charlie
>(Encoded1) writes:
>>Subject: PROCS or no PROCS?
>>Date: 08 May 1998 03:30:30 GMT
>>I'm a PICK programmer. Just wondering how marketable PROC programming
>>knowledge is....
>IS Director
>Affiliated Acceptance Corp
>3101 Mercier, Ste 407
>Kansas City, MO 64111
></PRE></HTML>
not marketable, but a bit like shell programming, so if you understand
programming you should just add it to your resume as PICK shell
programming urp !
> I'm a PICK programmer. Just wondering how marketable PROC programming
> knowledge is....
who (other than henry) can program in BATCH ????
>> I'm a PICK programmer. Just wondering how marketable PROC programming
>> knowledge is....
dave.
------_-_------------------------------------------------------------------
| o o | David Rose, | .--_|\ |
| ! | Holiwill Pty Ltd, | / \ |
| '''=``` | Australia. | \_.--.*/ |
-------~-----------------------------------------------------------------v-
Most people I know think that I am crazy (.. Billy Thorpe circa 1973)
Especially the "application programmers" on comp.databases.pick (me circa 1994)
It must be close to 15 years since they took the BATCH section out of the
Microdata PROC manual. AFAIK nobody has done anything much with BATCH
since BASIC hit its stride. Remember the DELETE PROC? That turkey seemed
to have a life of its own. I distinctly recall using "COPY ... (O,D" (note
the comma!) to delete items from PROC without dropping to TCL because
DELETE was a PROC itself. All of which just goes to show I should have
been using BASIC except that this predated the EXECUTE statement. Why
don't I miss those days?
IAC, I'm pleased to report that, B/ADD and B/DEL being illegal names for
UNIX files, jBASE does not support them. <g>
--
Luke Webber
* Note: The opinions expressed by Luke Webber are in no way supported *
* by his employers, Luke Webber Consulting Services *
>>not marketable, but a bit like shell programming, so if you understand
>>programming you should just add it to your resume as PICK shell
>>programming urp !
>going a bit further down the same path ...
>who (other than henry) can program in BATCH ????
And, since I never could remember which was which of Y22 and Y23, I've
still got the manual around here somewhere. You never know when you
might need it.
--
-- Mike Barnes, Owner, Exodus Computer Systems, Stockport, England.
-- If you post a response to Usenet, please *don't* send me a copy by e-mail.
Me too. But it was a loooong time ago. And my mother made me wash my handsQuote:>>who (other than henry) can program in BATCH ????
>Me, Me, Me!
>And, since I never could remember which was which of Y22 and Y23, I've
>still got the manual around here somewhere. You never know when you
>might need it.
Jim Harger
1. Output/Return Values from PROCS within PROCS
Okay heres the situation:
Ive got a stored proc that accepts input params and these input params
are then passed onto either one of 2 procs (within the same master proc)
depending on the user's id. The reason for passing to a choice of
anyone of these 2 sub procs. i.e
1. MAIN PROC
CREATE procedure MyProcedure_1
as
--the identity from either one of the sub procs]
begin
set nocount on
--referenceid number to return back
set nocount off
end
GO
2. SUB PROC
In each of the procs I have:
different from 0 now in the MAIN PROC because it was altered in the SUB
Please can some one point out why am I not getting the right output
Cheers K.Y
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
2. Need Help on Informix Data Director for VB
3. Problem with s.Procs calling s.Procs
4. Undocumented error message in SQL Server 2000
6. SQL IDENTITY
7. stupid question 437 - basing stored procs. on existing stored procs.
8. How does SQL7 scale from 4 procs to 8 procs on Win2K?
9. System stored procs (starting with 'dt') changed to user stored procs
10. Stored Procs calling Oracle's "stored procs"
11. SQL Server DB has 100's of Stored Procs that are duplicates of std Stored Procs?
12. Stored Procs, Parameters and Access Runtime