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.

Reply via email to