Dumb VFP front end, SQL directly update, inserts, deletes 
Author Message
 Dumb VFP front end, SQL directly update, inserts, deletes

Hi,

I was just wondering if anyone has build an application based on running the
updates, inserts and deletions right on the server, either thru sending the
commands there, or calling stored procedures. Basically the VFP front end is
a dumb client.

Has anybody written an application like this? If so, what are the advantages
and disadvantages from your experience?

Thanks.



Tue, 30 Aug 2005 11:40:08 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
Hi Roy,

I think DataClas COM handles data this way.
http://www.redmatrix.com/default.asp?section=dataclascom. You can look
through the documentation at
http://www.redmatrix.com/downloads/dataclascom.pdf.

--
Cindy Winegarden  MCSD, Microsoft Visual FoxPro MVP

http://msdn.microsoft.com/vfoxpro  http://foxcentral.net


Quote:
> I was just wondering if anyone has build an application based on running
> the
> updates, inserts and deletions right on the server, either thru sending
> the
> commands there, or calling stored procedures. Basically the VFP front end
> is
> a dumb client.

> Has anybody written an application like this? If so, what are the
> advantages
> and disadvantages from your experience?



Tue, 30 Aug 2005 12:49:30 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
Do you mean without remote views, and without sql-pass-through???
or did you mean with?
lemme know ??
mondo regards [Bill]

--
=============================[remove the dot bob to reply]
William Sanders, Electronic Filing Group. MSDN ISV - VFP/SQL .  mySql/ Sql /
Oracle with VFP - YUP!!
 GoTo China and teach C/SaPPdEV on occasion.  http://window.to/vfoxpro

Quote:
> Hi,

> I was just wondering if anyone has build an application based on running
the
> updates, inserts and deletions right on the server, either thru sending
the
> commands there, or calling stored procedures. Basically the VFP front end
is
> a dumb client.

> Has anybody written an application like this? If so, what are the
advantages
> and disadvantages from your experience?

> Thanks.



Tue, 30 Aug 2005 17:52:55 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
i'm sure tons of apps are written like this right now.  remote views have
the inserts/deletes/etc. run on the server... that's what client server is
all about...

two easy choices for VFP are MSDE (free and SQL Server compatible) or SQL
Server itself.

Advantages:
Way more robust.
For apps with many users, it is way, way faster.
Much more secure.
More scalable.

Disadvantages:
Can take longer to code.
Requires you abandon your row based thinking of xBase and move up to set
based thinking.
Can be more complex.


Quote:
> Hi,

> I was just wondering if anyone has build an application based on running
the
> updates, inserts and deletions right on the server, either thru sending
the
> commands there, or calling stored procedures. Basically the VFP front end
is
> a dumb client.

> Has anybody written an application like this? If so, what are the
advantages
> and disadvantages from your experience?

> Thanks.



Wed, 31 Aug 2005 00:58:56 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
One advantage to doing it this way is that your database is more secure. You
would only have to grant execute permissions to the users for executing the
stored procs.

The trade-off is that you'd probably have to write a maintenance SQL script
that would dynamically regenerate all of your insert/update/delete stored
procs in the event that you change your underlying table structure
defintions.

Jon


Quote:
> Hi,

> I was just wondering if anyone has build an application based on running
the
> updates, inserts and deletions right on the server, either thru sending
the
> commands there, or calling stored procedures. Basically the VFP front end
is
> a dumb client.

> Has anybody written an application like this? If so, what are the
advantages
> and disadvantages from your experience?

> Thanks.



Wed, 31 Aug 2005 08:30:52 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
Hi,

Forgot to make it clear, I want to use sql passthru to send the commands or
maybe send parameters to a stored procedure on Sql Server. No remote views,
some local cursors, but not updatetable, just for display purposes.


Quote:
> Do you mean without remote views, and without sql-pass-through???
> or did you mean with?
> lemme know ??
> mondo regards [Bill]

> --
> =============================[remove the dot bob to reply]
> William Sanders, Electronic Filing Group. MSDN ISV - VFP/SQL .  mySql/ Sql
/
> Oracle with VFP - YUP!!
>  GoTo China and teach C/SaPPdEV on occasion.  http://window.to/vfoxpro


> > Hi,

> > I was just wondering if anyone has build an application based on running
> the
> > updates, inserts and deletions right on the server, either thru sending
> the
> > commands there, or calling stored procedures. Basically the VFP front
end
> is
> > a dumb client.

> > Has anybody written an application like this? If so, what are the
> advantages
> > and disadvantages from your experience?

> > Thanks.



Sun, 04 Sep 2005 10:20:52 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
Thanks Jon,

Now has anybody written an application like this? I'm thinking that most
people that choose to run the commands on the server probably use stored
procedures to do the inserts/updates/deletes. Any particular strategy for
this? a stored procedure for every table? or a generic one for all? How
about handling update conflicts when one user modified a record while it was
being edited?

Thanks


Quote:
> One advantage to doing it this way is that your database is more secure.
You
> would only have to grant execute permissions to the users for executing
the
> stored procs.

> The trade-off is that you'd probably have to write a maintenance SQL
script
> that would dynamically regenerate all of your insert/update/delete stored
> procs in the event that you change your underlying table structure
> defintions.

> Jon



> > Hi,

> > I was just wondering if anyone has build an application based on running
> the
> > updates, inserts and deletions right on the server, either thru sending
> the
> > commands there, or calling stored procedures. Basically the VFP front
end
> is
> > a dumb client.

> > Has anybody written an application like this? If so, what are the
> advantages
> > and disadvantages from your experience?

> > Thanks.



Sun, 04 Sep 2005 10:24:35 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes


Quote:
> Thanks Jon,

> Now has anybody written an application like this? I'm thinking that most
> people that choose to run the commands on the server probably use stored
> procedures to do the inserts/updates/deletes. Any particular strategy for
> this? a stored procedure for every table? or a generic one for all? How
> about handling update conflicts when one user modified a record while it
was
> being edited?

> Thanks

Only if you absolutely love programming in T-SQL -}

-Anders



Sun, 04 Sep 2005 18:19:55 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
We're doing something similar for this for a small app we're writing.
Currently, I'm using a stored proc for each purpose (I/U/D) for each table.
Since the number of fields can differ between tables I think you have to do
it this way because the number of declared parameters to the procs (i.e.
field values for an insert/update) could differ. Maybe there is a way to
accommodate this in a more generic one but I don't have the time to expand
my cranial capacity that much. :)

For our initial version of this app, we're not worrying about update
conflicts at this point since there won't be such heavy use, but at some
point we'll be looking into the possibility of locking other users out while
a record is being edited.

Jon


Quote:
> Thanks Jon,

> Now has anybody written an application like this? I'm thinking that most
> people that choose to run the commands on the server probably use stored
> procedures to do the inserts/updates/deletes. Any particular strategy for
> this? a stored procedure for every table? or a generic one for all? How
> about handling update conflicts when one user modified a record while it
was
> being edited?

> Thanks



Sun, 04 Sep 2005 21:11:13 GMT  
 Dumb VFP front end, SQL directly update, inserts, deletes
My applications use 4 stored procedures for each table. One for Adds,
one for updates, one for deletes, and one for field and table level
validations which is called from the other 3.

These stored procedures are the only access to my tables and they
handle things like rolling down updates to dependent tables, cascading
deletes, creating an audit trail and more.

these procedures can be accessed from my user interfaces or from other
applications and import utilities. This ensures that my database's
data is always valid.

The thing that is different about my stored procedures and UIs is that
I don't write them. I have written an application generator that does
all this for me. All I need to do is create the tables and answer a
few yes or now questions about each table. The generator does the
rest.

Write back or call 201 665 8906 if you need more information
Best to you,
John



Mon, 05 Sep 2005 11:08:27 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. VFP as front end for SQL Server 6.5

2. VFP as front end for SQL server?

3. Views SQL Update or Delete then Insert.

4. Please Help on Sql Insert/Update/Delete

5. Please Help on Sql Insert/Update/Delete

6. Windows front end and Web server back end?

7. Front-end back-end Access, FP, VB aaarghh

8. Why use Foxpro as SQL front-end? (opinions,

9. using Fox as an SQL front-end

10. VisualFox as SQL server Front End

11. FPM 2.6 as front-end to SQL Server

12. VFP 3.0 Front End to Oracle 7 database

 

 
Powered by phpBB® Forum Software