Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Handling lots of data keys
Message
From
31/01/2000 15:05:45
Isabel Cabanne
Hubbard Woods Software, Inc.
Winnetka, Illinois, United States
 
 
To
31/01/2000 14:22:23
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
00325065
Message ID:
00325249
Views:
24
John,

> OK, so then you are using surrogate keys. Good deal. In that case, and in conjunction with the way you are allowing edits, you might want to consider a GenKey property in a data service tier and to keep the physical structure of your keys all the same.

By this do you mean for retrieving a new key? If so, that part is already taken care of.

> Now, as to tracking, I think the problem will resolve itself if you table buffer the children, use a parametized view for children,

Although I have a VFP database, the client tier never interacts directly with it. The client tier asks the middleware for the data and has no knowledge of where it's coming from. Updates are sent to the middleware with instructions about the form in which the data is arriving and what data it applies to. I've got a firewall betwen the UI and the DB, and want to keep it that way. Also, I've left my DB in a pretty wide open state so that the model can accommodate a variety of business situations. I don't want my cascaded deletes, etc. built into it becuase the rules are in the middleware and are subject to change. Call me whacky, but I am intentionally keeping programmatic control over RI.

> and do not allow a change of the parent record pointer if a child edit is occurring.

In place already.

I think maybe I'm not explaining myself well - won't be the first time. It's all the UI movement that creates the key mess.

You click on a list and the pointer moves and you refresh the data and related, changed pointers. You click the Add button and add a blank record and need to also blank out the child data by way of removing the parent key, but still need to keep the original parent key around so you can refresh back to the correct record if the changes are abandoned. You add a new record, and have a set of nicely cleaned out keys, but then the user selects from a pick list of people and you have to update some of the keys so you can find appropriate addresses, and run the data retrieval code for getting those addresses, but once again you don't want that new key to stick around if there's a refresh. Etc., etc. Those are some of the cats I'm trying to herd.

Thanks for the suggestions, which I'll hold on to. I appreciate the time.

BTW, just the process of writing this out has given me more ideas on how to handle me key mess. I'll get there.

Isabel
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform