From: Stefan Wuebbe
To: prasanna kunder
Visual FoxPro 9
Databases, Tables and SQL Server
Friday, March 22, 2013 4:00:32 PM
This message was rated by:
# Ratings: 2
> > How would you describe the problem you are currently having, is it about using classes in general?
> > As a nutshell description of how I'd do it:
> > I'd start by creating a custom "base" class in a VCX, similar to what Cetin posted here called "caGeneric".
> > That class would look relatively complex at first glance, and actually is a master piece.
> > But it's "generic", hence reusable, so that complexity would not matter at all, your advantage would be the "reusability":
> > You'd probably create another class based on the first according to your particular requirements, say decide whether it's using ODBC or ADO and what back-end make and model, or "native" DBFs
> > Then you would create your concrete classes based on the second:
> > There you would determine the From table name, perhaps the field list, that's all, perhaps only two or three porperties (because the sophisticated base class is doing all the work for you).
> > Then you can drag&drop the concrete classes wherever you need it, for example on a custom myDataEnvironment class that can contain one, two or more CA instances, each being dedicated to a "topic", like "info", "customers", "Invoices" whatever.
> > There are alternate approaches, like the one that Bernard Bout describes in the Foxite -> Home -> Articles section.
> > Does that help?
> > -Stefan
> ok, sir
> if i have 3 table with in one form
> then i need 3 CA instances
I believe I had understood that part already, and the previous description attempt is what I thought might help.
So I'm a little helpless now because I do not know whether
the previous description was not well written so that it's not understandable,
or the approach is somehow different from something you have in mind and did no tell yet,
or whether certain details are not clear and if so what details,
or something else?
As a reworded attempt:
if you are used to use DBF table aliases, perhaps being visually added to a Form.DataEnvironment,
then you would add one alias or DE.Cursor object per table to the DataEnvironment.
And each alias would have its own properties, like alias name, linked DBF table (CursorSource) and so on.
Whereas what you would not do is using only one alias for all tables.
Same with your CursorAdapters: you would use one CA per table, so that each one would represent the table, be the "CustomersTable" or "InfoTable" object so to say.
Hence each CA instance would have the appropriate properties content being set, like caCustomers.SelectCmd for instance.
Any problems so far?
Now where do those "CustomerCursorAdpater" or "InfoCursorAdpater" come from?
They would probably be in a "Class Library" (VCX) that you created yourself in the Project Manager's "Classes" tab.
The library, or libraries, would contain the classes that you created as described previously or using a "builder" approach as described by Marc and Bernard.
Where do you drop them?
You can drop them on any "container" object, like a Form, Container.
What I usually do is using custom "myDataEnvironment" classes that provide some reusable "parent" functionality, like connection handle(s), Update() and Revert() methods that would cascade each members.Update() (within a Transaction) or Revert() or whatever() methods, stuff like that
Posted by prasanna kunder @ 3/21/2013 7:58:37 PM
Posted by Stefan Wuebbe @ 3/21/2013 11:51:03 PM
Posted by prasanna kunder @ 3/22/2013 6:43:14 AM
Posted by prasanna kunder @ 3/22/2013 6:50:40 AM
Posted by Stefan Wuebbe @ 3/22/2013 7:26:13 AM
Posted by prasanna kunder @ 3/22/2013 3:03:29 PM
Posted by Stefan Wuebbe @ 3/22/2013 4:00:32 PM
Posted by prasanna kunder @ 3/22/2013 5:36:11 PM
Posted by Om Rajan @ 3/22/2013 7:50:28 PM