Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

2 problems (GPF & filter) & 2 questions (caseno & lname-fname)

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
I have two problems with p9 (or me) and two questions:

Problem 1: Last week I filtered my database. Now, each time I reload the database, the filter is still active. How do I get it to go away so that next time I run p9, there are no filters?

Problem 2: For about 6 months now, I get a GPF upon exiting p9. Runs ok on re-load, but occasionally, I have to reboot and re-initiate p9 for things to work ok. How to solve?

Question 1: I have a database of client information that has about 300 records in it now. Is there a way that I can add a casenumber field and get p9 to assign a unique case number to each record...retroactively? Or...will I have to go in and key in a case number with each record?

Question two: In the same database described in question 1, I have a field called "name", in which I insert:

Lastname, Firstname

Is there a way to rename the "name" field to "lastname", and add another field called "firstname"...and get p9 to split the two at the comma...or will I have to do this manually?
 
Problem 1: Open your form in "Design" Mode right-click on the field with the filter. Remove the filter data and re-save the form.

Problem 2: Not enough information about this. Typically caused by a corrupted table, form, or report that generates a page fault error.

Question 1: You 'can' create an autoincrement field that will work, but most of us strongly advise against it. It can cause problems linking data later on. The best bet is to create a table that holds the next casenumber. Use a tCursor to get that number, increment it and apply it to the record being created. You can populate the existing table with casenumbers by using this technique in combination with a scan.

Question 2: Yes, use the breakApart() function in combination with a scan.

Mac :)

"Do not delve too deeply in the arts of your enemy and so become ensnared by them"

langley_mckelvy@cd4.co.harris.tx.us
 
Hey, guys...Lance (over at wpuniverse) posted a GREAT response to the p9 problems I noted. I'm reproducing it here for the benefit of others who may have experienced one or more of the same problems. Great gratitude for Lance and his unselfishness with his time in helping a general database flunky like me!
=========================================================Daniel,

Re: Problem 1:

I assume you mean you filtered your table from within a form. (Paradox doesn't save filters associated with Table windows).

In that case, it's most likely that you saved your form after applying the filter. The easiest way to fix that is to:

1. Open the form in a Design window.
2. Choose Format | Filter.
3. Erase your filter criteria and then choose OK.
4. Re-save your form.

Re: Problem 2:

I've seen a lot of different therioes on this, but the most reliable one (in my experience) is related to a stylesheet problem. See this article for details and links to other related articles.

re: Question 1:

Yes, there is a way. There are a few, actually. The easiest one is also the most problematic when more than one machine starts using the table. So I generally advise using it.

Instead, do something along these lines:

1. Add a LongInt field to your table, perhaps called CaseNumber.

2. From the main menu, choose File | New | Script and then type the following code:



code:--------------------------------------------------------------------------------
var
tc TCursor
endVar

if not tc.open( "Tablename.db" ) then
errorShow( "Can't Update Case Numbers",
"Use [>>] for details..." )
else
tc.edit()
scan tc :
tc."CaseNumber" = tc.RecNo()
tc.unlockRecord()
endScan
tc.endEdit()
tc.close()
endIf
--------------------------------------------------------------------------------


3. When you have it typed in, choose Program | Compiler Warnings and Program | compile with Debug. (These will give you more informative error messages, should you have any.

4. Press F9 to make sure you have made any typos. If you haven't, you'll see the message "No syntax errors" appear in the status line.

5. Save your script and then run it.

When it finishes, which shouldn't take long at all, you should have a unique number in [CaseNumber] for each record.

NOTE: If you want to use CaseNumber as the key field, do not define it as the key field when you add it in Step 1. Add it to the end of the table, run the script, and then move the field to the first field position. Otherwise, you will run into problems with the above script. (It's called "flyaway" and would require a bit longer to fully discuss at the moment. For now, just don't do that.)

re: Question 2:

You can certainly rename the name field to lanst name and add a firstname field; however, Paradox really doesn't have any way of knowing if the existing data always matches the lastname, firstname format.

So, you need to break the names apart, but you don't have to do it manually. If you're sure all your names match, then you can use another script to separate the names and assign them to the appropriate fields:


code:--------------------------------------------------------------------------------
var
tc TCursor
strFull,
strFirst,
strLast String

endVar

if not tc.open( "Tablename.db" ) then
errorShow( "Can't Update Case Numbers",
"Use [>>] for details..." )
else
tc.edit()
scan tc :
; Assuming you've already restructured the table
strFull = tc."LastName"
if strFull.match( "..,..", strLast, strFirst ) then
tc."FirstName" = strFirst
tc."LastName = strLast
tc.unlockRecord()
endIf
endScan
tc.endEdit()
tc.close()
endIf
--------------------------------------------------------------------------------


Again, you'll want to save your script as outlined earlier. Once you run it, open the table and see if all the records were changed as you expected. If so, you're done; otherwise, there may be a few records that didn't match precisely.

While it seems like a little bit of work, it's part of the data conversion process. (And is one reason why nearly every book on the subject will tell you that a little bit of advance planning can save time down the road.)

Hope this helps...

-- Lance

__________________
Neither courtesy nor sense is common; cultivate both -- me.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top