Nothin' like all members of the choir singing from the same score,
however ... before the trainwreck is set in motion. When working in a
"team" (your situation), everyone would do well to be reading the same
notes. Hence, R:Documenter.
Bruce
Bruce A. Chitiea
SafeSectors, Inc.
-----------------------------------
112 Harvard Ave #272
Claremont CA 91711-4716
-----------------------------------
rby...@safesectors.com
-----------------------------------
+011 (909) 238-9012 c
+011 (909) 912-8678 f
------ Original Message ------
From: "'Karen Tellef' via RBASE-L" <rbase-l@googlegroups.com>
To: "rbase-l@googlegroups.com" <rbase-l@googlegroups.com>
Sent: 8/4/2020 6:50:14 PM
Subject: Re: [RBASE-L] - Re: Best practices?
Wow, I appreciate all the opinions! Thanks a bunch everyone!
So it looks like both dropping the temp tables at the end of the
program or checking existence of a temp table after its creation are
both used. I am going to check with my partner on this and suggest
that we adopt one of these methods. I'll let him decide (it's "his"
client)
Karen
-----Original Message-----
From: Michael Byerley <bauer...@gmail.com>
To: RBASE-L <rbase-l@googlegroups.com>
Sent: Tue, Aug 4, 2020 11:39 am
Subject: [RBASE-L] - Re: Best practices?
I do #2 as a matter of routine, so a choice can be made based on the
current desire.
On Monday, August 3, 2020 at 4:40:31 PM UTC-4, Karen Tellef wrote:
Hard to believe in my decades of programming that this is the first
time this has happened. Just wondering if other programmers have tips
on this situation for the future. And I'm kinda bored this afternoon
so thought I would post.
History: I work on this company's stuff with another programmer. We
work independently, each of us handling different "areas" of the
business. The company's contact himself also does a bit of
programming. So 3 of us writing programs.
I write a new program today, works great for me, he keeps claiming it
doesn't work for him, giving him my "no data to report" message. He
exits and comes back in, never works. I finally ask him exactly the
process he's going thru, and I find out that he will run another
program immediately before running this program. Aha, a clue.
Guess what. In that other program (written by the other programmer),
he creates a temp table (and doesn't drop it) using the same column
name that I have in my temp table, but as a different datatype! So my
temp table was never created because of the structure error, and it
reports no data!
So what's the best way to prevent this? I was thinking of things
like:
1. Each of us using temp column names using our initials (like: ktQty
INT). But even with that, there's no guarantee that I'll remember I
used a "ktQty" as a Double once, and as an Integer another time.
2. I could search program code for occurrences of each "new" temp
column name I want to use to see if any other program uses that name.
3. I could only use permanent column names, altho using the permanent
name "Qty" is not as descriptive as a temp column name like:
tmpQtyToShipByMonthend
But in reality there's 3 "easy" things I could do:
1. We could drop our temp tables at the end of our programs. None of
us do this. I like leaving them around in case I run something from
the menu and want to get to the R> prompt to see temp table data. Do
you all drop temp tables?
2. After every "create temp table" do a "select ... from sys_tables"
to see if the temp table exists. Seems the easiest, doesn't it?
Again, do any of you routinely do this?
3. Or.. I can figure that since this has happened once in the >20 yrs
that I've worked on that account, figure that it's most likely not
going to happen again so don't worry about it.
Just some Monday musings......
Karen
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google
Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to rbase-l+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rbase-l/29634058-c9c6-468b-968b-fdaff81eccd9o%40googlegroups.com
<https://groups.google.com/d/msgid/rbase-l/29634058-c9c6-468b-968b-fdaff81eccd9o%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google
Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to rbase-l+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rbase-l/1089143363.62647.1596592214893%40mail.yahoo.com
<https://groups.google.com/d/msgid/rbase-l/1089143363.62647.1596592214893%40mail.yahoo.com?utm_medium=email&utm_source=footer>.
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rbase-l+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rbase-l/emfc0d1980-3dfe-408b-9c2b-9d1822ecafcb%40pathfinder.