Free Tables vs DBC 
Author Message
 Free Tables vs DBC

Hi (it's me again, :) )

I only work with free table because I like to control everything...so I can
be sure about my aplication...I create an index...I delete it...and so on...

My question is: (if possible some code example)

1) How I can create a view if I can only create a view with DBC?

2) If a create a view...that's mean that is a copy of the original
table...and if so...if I update or delte or append a record in this
view...this mean that I have to do the same thing with my original table??

3) I always use variable when I want to show or change a record in a
table..and I have some buttons where a have define one button that save or
not the changes in the record. Is this a good way ? (remenber that I want
that end user to have total control with the application)

4) I have many apps in clients that have network...so in this case how I can
make may app faster and more optimize with data access, what I mean to say
is there is any technics for optimize apps in networks? and if so what they
are?

for now is enougth.

TIA  :)

Once again, sorry with my english....



Mon, 29 Aug 2005 20:27:52 GMT  
 Free Tables vs DBC

Quote:
> Hi (it's me again, :) )

> I only work with free table because I like to control everything...so I
can
> be sure about my aplication...I create an index...I delete it...and so
on...

> My question is: (if possible some code example)

> 1) How I can create a view if I can only create a view with DBC?

Umm, create a DBC and then create a view in the DBC.
Here is the beginning of my program that inserts data into a remote SQL
Server database.
Sorry, it is both long and lifted from the program incompletey but you
should get the jist of what I am doing - create a database, create a
connection in the database, create a remote view in the database that uses
the connection and set a billion properties. Probably a lot of people would
design the view with the GUI, and save it. I've done this the long
programmatic way so that if it screws up people can just delete the .dbc and
rerun the program.

* if DBC file isn't there, create it.
IF !FILE('codalink.dbc')
 * create a database and define the ODBC connection
 CREATE DATABASE codalink

 * these memvars have the datasource name, username and password..
 CREATE CONNECTION codaconn ;
   DATASOURCE ALLTRIM(m.odbcconn) ;
   USERID ALLTRIM(m.odbcusr) ;
   PASSWORD ALLTRIM(m.odbcpass)

 * create an empty view for each table (this saves dragging loads of data
over the landline. I'm only inserting records so I just need the
structure..)
 CREATE SQL VIEW linkhead ;
  REMOTE CONNECTION codaconn ;
  AS SELECT * FROM oas_linkhead lh;
   WHERE lh.linkcode='<><><><>'

 * table in the view
 ?DBSETPROP('linkhead','VIEW', 'Tables', 'oas_linkhead')

 * local to remote field mapping for updating
 ?DBSETPROP('linkhead.linkcode', 'FIELD',
'UpdateName','oas_linkhead.linkcode')
 ?DBSETPROP('linkhead.cmpcode', 'FIELD',
'UpdateName','oas_linkhead.cmpcode')
 ?DBSETPROP('linkhead.doccode', 'FIELD',
'UpdateName','oas_linkhead.doccode')
 ?DBSETPROP('linkhead.docnum', 'FIELD', 'UpdateName','oas_linkhead.docnum')
 ?DBSETPROP('linkhead.posted', 'FIELD', 'UpdateName','oas_linkhead.posted')
 ?DBSETPROP('linkhead.yr', 'FIELD', 'UpdateName','oas_linkhead.yr')
 ?DBSETPROP('linkhead.period', 'FIELD', 'UpdateName','oas_linkhead.period')
 ?DBSETPROP('linkhead.curdoc', 'FIELD', 'UpdateName','oas_linkhead.curdoc')
 ?DBSETPROP('linkhead.docdate','FIELD', 'UpdateName','oas_linkhead.docdate')
 ?DBSETPROP('linkhead.authuser','FIELD',
'UpdateName','oas_linkhead.authuser')
 ?DBSETPROP('linkhead.descr', 'FIELD', 'UpdateName','oas_linkhead.descr')

 * tell it about the key fields
 ?DBSETPROP('linkhead.linkcode', 'FIELD', 'KeyField', .T.)
 ?DBSETPROP('linkhead.cmpcode', 'FIELD', 'KeyField', .T.)
 ?DBSETPROP('linkhead.doccode', 'FIELD', 'KeyField', .T.)
 ?DBSETPROP('linkhead.docnum', 'FIELD', 'KeyField', .T.)

 * tell it which fields we are allowed to update
 ?DBSETPROP('linkhead.linkcode', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.cmpcode', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.doccode', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.docnum', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.posted', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.yr', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.period', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.curdoc', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.docdate', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.authuser', 'FIELD', 'Updatable', .T.)
 ?DBSETPROP('linkhead.descr', 'FIELD', 'Updatable', .T.)

 * turn on the "master switch" for updating the view
 ?DBSETPROP('linkhead', 'VIEW', 'SendUpdates', .T.)

*....etc....
*
ELSE
 OPEN DATABASE codalink
ENDIF

SELECT 0
USE linkhead       && this is a view as defined above, right?

* insert into the local view
INSERT INTO linkhead (linkcode, cmpcode, doccode, docnum) ;
                VALUES ("blah", "blah", "blah", "blah")
* commit change to remote table
=TABLEUPDATE()

Quote:

> 2) If a create a view...that's mean that is a copy of the original
> table...and if so...if I update or delte or append a record in this
> view...this mean that I have to do the same thing with my original table??

TABLEUPDATE() as above

Quote:

> 3) I always use variable when I want to show or change a record in a
> table..and I have some buttons where a have define one button that save or
> not the changes in the record. Is this a good way ? (remenber that I want
> that end user to have total control with the application)

> 4) I have many apps in clients that have network...so in this case how I
can
> make may app faster and more optimize with data access, what I mean to say
> is there is any technics for optimize apps in networks? and if so what
they
> are?

The basic strategy is to only get the data you will work on. Where I created
a very static view up there, you would probably create a parameterised view,
ie the WHERE clause uses variables. Then you update those variables and
issue REQUERY() to get the different recordset from the remote database
without redefining views etc.

I am not experienced with remote databases, this is the =only= thing I've
ever done with them and it only inserts data. But it works, and maybe you
will see answers to some things that aren't immediately obvious.
The most annoying thing I found when trying to get stuff going is when the
local view doesn't represent the external data and you just want to cancel
everything, you can't just close the views, you have to revert them first.

HTH
--
Andrew Howell



Mon, 29 Aug 2005 21:07:00 GMT  
 Free Tables vs DBC
A couple of things Andrew did not mention.....:

Quote:
> 2) If a create a view...that's mean that is a copy of the original
> table...and if so...if I update or delte or append a record in this
> view...this mean that I have to do the same thing with my original table??

No, not a permanent copy. A view is just a SQL select statement that
executes when you USE the view. The only thing that "lives" in the DBC is
the SQL statement.

Quote:
> 3) I always use variable when I want to show or change a record in a
> table..and I have some buttons where a have define one button that save or
> not the changes in the record. Is this a good way ? (remenber that I want
> that end user to have total control with the application)

So in other words, you're writing a whole lot of code to build an edit
buffer. VFP has this built in. Check out CursorSetProp("Buffering"),
TableUpdate() and TableRevert() in the help file.

Dan



Tue, 30 Aug 2005 01:11:16 GMT  
 Free Tables vs DBC
Thanks both...but still....I have many doubts...


Quote:
> A couple of things Andrew did not mention.....:

> > 2) If a create a view...that's mean that is a copy of the original
> > table...and if so...if I update or delte or append a record in this
> > view...this mean that I have to do the same thing with my original
table??

> No, not a permanent copy. A view is just a SQL select statement that
> executes when you USE the view. The only thing that "lives" in the DBC is
> the SQL statement.

> > 3) I always use variable when I want to show or change a record in a
> > table..and I have some buttons where a have define one button that save
or
> > not the changes in the record. Is this a good way ? (remenber that I
want
> > that end user to have total control with the application)

> So in other words, you're writing a whole lot of code to build an edit
> buffer. VFP has this built in. Check out CursorSetProp("Buffering"),
> TableUpdate() and TableRevert() in the help file.

> Dan



Tue, 30 Aug 2005 03:07:51 GMT  
 Free Tables vs DBC
Hi Aramini,

What are your doubts?

Go to http://www.peisch.com/downloads.html and download views.zip.  It has
wonderful examples.  Barbara generally only uses free tables and a dbc for
views.

pamela

Quote:
> Thanks both...but still....I have many doubts...



> > A couple of things Andrew did not mention.....:

> > > 2) If a create a view...that's mean that is a copy of the original
> > > table...and if so...if I update or delte or append a record in this
> > > view...this mean that I have to do the same thing with my original
> table??

> > No, not a permanent copy. A view is just a SQL select statement that
> > executes when you USE the view. The only thing that "lives" in the DBC
is
> > the SQL statement.

> > > 3) I always use variable when I want to show or change a record in a
> > > table..and I have some buttons where a have define one button that
save
> or
> > > not the changes in the record. Is this a good way ? (remenber that I
> want
> > > that end user to have total control with the application)

> > So in other words, you're writing a whole lot of code to build an edit
> > buffer. VFP has this built in. Check out CursorSetProp("Buffering"),
> > TableUpdate() and TableRevert() in the help file.

> > Dan



Wed, 31 Aug 2005 01:27:55 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Free tables vs dbc

2. DBC vs. Free Tables in ODBC

3. .dbc vs. free tables

4. dbc VS Free tables

5. dbc vs free table

6. Database table vs Free table ?

7. Set relation problems between DBC and free tables

8. Performance of Free tables compared to within a DBC

9. How to import hundreds of free table to one DBC

10. Free Tables to DBC - Is behaviour different?

11. Databases vs. Free Tables

12. DBF vs Free Tables

 

 
Powered by phpBB® Forum Software