1 |
A Newsletter for
FoxPro
Application Developers in Southern California
|
I ran into a problem in a table in which the client assigned the value to the primary key. The table is called PARTS and the primary key is PARTNUM. The client has to be able to assign the part number themselves. Using another field that they never see as the primary key is not really an option, since PARTNUM must be unique and would therefore be set up as a candidate key. The problem I ran into would occur on the primary key or a candidate key, so creating another field as the primary key was not really an option.
What the client was sometimes doing was deleting a part and then wanting to reenter it. This is what caused the problem. VFP would see the deleted primary key (say part number ‘VALVEOI’) and wouldn’t let the user reenter the same part number again. There were other ways of doing this same task. Locating the record and changing it is the same as deleting
it
and reentering it, but some users were not doing it that way for some reason. Since there are well over 50 users on this system and since I try to accomodate how the users want to work instead of asking them to accomodate how the program works, I came up with a solution.
One of the ways of allowing a primary key to be reused is to have the primary key be based on a conditional index. In my case, it would be”PARTNUM AND NOT DELETEDO”. This would mean that VFP would ignore the deleted occurance of a part number and if the user entered that part number again, VFP would accept it just fine.
This is an acceptable solution, but what if the deleted record ever gets recalled? Then you would have a problem. I wanted a way to avoid that admittedly unlikely problem. What I did was give the primary key of the deleted record a unique value that would never be used by a user.
To do this, I added some code to my base class delete method and called it only when instructed to do so by the delete method on a form. Since my primary keys are usually only character or
|
At LA Fox
March 15, 1999, 6:30 PM, Jonathan Melvin.
Jon Melvin will
describe VFP-based tools he has developed to manipulate SQL and to extract data from various ODBC databases and insert it into SQL server. He will also describe Active Server Page (ASP) procedures used to access the SQLserver data over the web. These procedures are “data-driven” (the web pages are
automatically formatted to match the structure of the data they are provided). Access is also secure. Users enter a usemame and password, and are allowed to access only certain fields in each table. All security (and other) parameters are passed as form variables in
the web pages so that SSL encryption will encrypt them, rather than being passed as part of the URL (the
more usual way). This VFP/SQLserver/ASP system is used in
production systems which provide both intranet and extranet access to data from various databases.
April 19, 1999, 6:30 PM, Rod Paddock. Rod Paddock is president and founder of Dash Point Software, Inc. DPSI based in Seattle, WA, specializes in developing applications and training software developers. DPSI develops with Visual lnterdev, VFP, VB and SQL Server. DPSI’s clients include: ADTC, SBT Accounting, The US Coast Guard, The US Navy, Pinnacle
Publishing, Intel and Azalea Software. Rod was a featured speaker at the 1996/1997 German FoxPro
DevCons, the 1995 and 1998 Visual FoxPro Developers Conference, the 1995-1997 FoxTeach conferences, and the 2nd Annual Southern California Visual FoxPro Conference. Rod writes for several database publications including:
Data Based Advisor, Foxtalk and Dbase
Advisor. Rod’s books include: VB5 for Web Development and VFP
5 Enterprise Development from Prima Publishing. Both of
|
Out and About
by Barry R. Lee
|
The March meeting of LA Fox will be held on March 15, 1999, at 6:30 PM at our regular meeting place (the Torrance Airport, 3301 Airport Drive, in Torrance). For details on how to get there, see the map on the back page.
|
FoxPro Q&A
Reapplying Default Values
|
Page 3
Page 4
Page 6
|
and much more
|
1 |