>Hi Ed
>
>I change my mind.
>
>Could you give me some examples or sample codes for me to learn the way in using Vfp in ODBMS, please?
>

Unfortunately, that's way beyond the scope of what I'd be able to cover here, both in terms of length of messages, and in terms of time spent by me ;:). Some simple examples of implementing save and restore logic were presented at DevCon a few years ago by Rod Paddock; you might try to find the text to Rod's presentation "Advanced Object Oriented Development" from FoxTeach in June of 1995 (Session O-4). He covers a simple example of object persistence in good detail there.

>Could you tell me why you think "especially with complex abstract object modelling, VFP is not going to get the job done easily", please?
>

VFP doesn't have the native data structures that are needed for complex modelling. Things like linked lists require a whole lot more work. There's no mechanism to store objects for things other than VFP (you have to write a whole lot of code to convert things to native FoxPro data types, and pointer thingys are pretty much out of the question without extensive interfacing in C/C++), and if you did store object state for a different environment, it would require a VFP COM server of some sort to be active to provide access to the stored objects, and then code would have to be written in the target environment to provide persistence support.

If you need an ODBMS, there are plenty of better choices than VFP as a starting point. If you want to stick with a relational model database, pick one with object extensions already built into the language (for example, Oracle).

>Thanks and thank you very much
>
>Sunny
>
>>>Would Vfp support 'persistence' which is the most important advance of ODBMS?
>>>
>>
>>You could implement persistent objects by implementing save and restore logic for each class, letting you save the state to a database, returning a unique ID for the saved object state, and then instantiating a new instance of the class and restoring the state from the saved state ID. This is not provided automagically, as it would be by an ODBMS, but would require fairly extensive programming. I've done this before where I've needed to maintain stateful business object persistence, creating a separate database to hold object state data.
>>
>>VFP is not going to perform automatic instance maintenance; you're going to have to add code so that whenever an object reference that may already be created is made, the current work environment is checked to see if it's presently in memory, and if not, go to the backing store and restore it. You'll have to implement logic to save objects whose persistence is by default longer than the current task, to make certain that multiple isntances of the persistent object are not instantiated at the saem time, and to remove objects from the backing store when they are destroyed in memory as well.
>>
>>If you really need an ODBMS, especially with complex abstract object modelling, VFP is not going to get the job done easily. I've used ObjectStore in the past, and where it's appropriate, it's a far better choice than trying to use VFP as a backing store for a set of wide-ranging persistent objects.
>>
>>>
>>>>It depends on what you mean by using it to creaste an object database. VFP is a relational model database, it could be used as an object storage table, relying on fields in tables to represent properties of an object and embedded links to other objects in the object table. You can save and restore objects explicitly in structures in the .DBF with some code added to your classes to support storage and retrieval of objects, and anything really strange can make use of memo/general fields as BLOBs. It's not ObjectStore, and it doesn't have the datatypes built into most object languages for creation and storage of objects with permanence, but you can store object states in tables