Doug:
#1 You drop temp tables "when leaving the form", what do you mean by that? If
you're creating temp tables to produce a report to the screen, where would you
drop those tables?
I usually put a hidden "set debug on" button on the main menu, and I could
enable that first, then run the program and do something like this (syntax not
checked)set var vtext = (cval('debug'))if vtext = 'off' then -- drop all temp
tablesendif
I guess that's not a lot of extra coding, and then I could set the debug on,
run the program, and my temp tables hang around for me to go to the r> prompt
to look at.
#2 I don't check for existence of a table, I always simply drop the table
before creating it, with 2038 set off. Of course, that doesn't have anything
to do with my immediate problem, because it was a different temp table created
by another program that caused my datatype mismatch.
#3 I like doing the project from permanent, with alter table syntax. Doesn't
help this situation because I can still add a column/datatype that is a
mismatch with an existing definition.
Karen
-----Original Message-----
From: Doug Hamilton <bugl...@wi.rr.com>
To: 'Karen Tellef' via RBASE-L <rbase-l@googlegroups.com>
Sent: Tue, Aug 4, 2020 2:45 pm
Subject: Re: [RBASE-L] - Best practices?
Random Comments:
Easy Thing #1: I drop temp tables when leaving the form. If I want to look
at the contents during processing, I have "Hide on Startup" pushbuttons that
each BROWSE a table.
To make them visible , I have a transparent flat 30x30 enhanced speed button
that runs PROPERTY cidHIDDEN% VISIBLE 'TRUE'. I put that button in the upper
left corner of my forms; when I mouse over it, its outline is visible.
Easy Thing #2: Use the function (CHKTABLE('tblview')) to test for existence
before you try to create it.
| Return Value | Status |
| 0 | table/view does not exist |
| 1 | permanent table |
| 2 | temporary table |
| 3 | server table |
| 4 | dBASE table |
| 5 | permanent view |
| 6 | temporary view |
I create temp tables from a permanent table using PROJECT TEMPORARY tTableName
FROM TableName USING * +
WHERE LIMIT = 0. That way columns are consistently defined.
If I need additional columns, I use ALTER TABLE tTableName ADD COLUMN
NewColumn [def...]
Doug
On 8/3/2020 3:40 PM, 'Karen Tellef' via RBASE-L 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/2069458979.877585.1596487225564%40mail.yahoo.com.
| | This email has been checked for viruses by Avast antivirus software.
www.avast.com |
--
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/0ccff58f-25a1-7f40-523c-e0042bc12957%40wi.rr.com.
--
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/1443237851.74138.1596592094607%40mail.yahoo.com.
