Anthony,
I thought sure I was the only one who would have thought of storing code in
sql server. Really wasnt sure at the time why I did it, but once I worked,
the idea is more in line with how I feel computers should work
Big Ass Dumb database backend, ! Great concept VFP make a nice gui for the
users, but use a nice solid datasotre in the back room.!
Bob Lee
----- Original Message -----
From: "Testi, Anthony L (UseTemp)" <anthony.testi-eds (at) eds D.OT com>
To: "'ProFox Email List'" <profox@leafe.com>
Sent: Friday, May 30, 2003 12:43 PM
Subject: RE: A little help with VFP -> SPT
> That is one of the core techniques used in my last programming project.
We
> treated the BackEnds as just big dumb databases. We had one table that
> stored our SQLs. There where multiple columns: SQL_NAME, Common, VFP,
> MS_QSL, Oracle, mySQL.... Normally only the name and common was filled
in.
> If the SQL was so complex and had to use specific Language commands such
as
> IIF for Fox vs. Case for MS SQL we would fill in the other columns.
>
> Also our framework had built in standard SQLs so that there was no need to
> add in many records to the SQL table. Commands such as:
> Get_Cursor_by_Primary_Key( <Table_Name>, <Primary Key Value>),
> Get_Cursor_All_Records( <Table_Name> ), Get_Cursor_by_Field( <Table_Name>,
> <Field_Name>, <Field_Value> ) Etc.
>
> We dealt with Vars in the SQL statements etc. Worked out well. We could
and
> did switch different backends on a daily bases.
>
> Anthony
>
> -----Original Message-----
> From: Bob Lee [mailto:bobl (at) wginc D.OT org]
> Sent: Friday, May 30, 2003 9:27 AM
> To: ProFox Email List
> Subject: Re: A little help with VFP -> SPT
>
>
> so last year, I got to thinking myself about SP's and when they could be
> used, and why. What I did was write a few lines of code which allowd me to
> store a SP - in a table, (say a sp table ) which could keep lib routines
for
> that database. this way, a user be it PHP programmer, or myself or
someone
> else could get access to a sql querry - as data, and then send it back to
> the server with their own var's filled in.. in cocept it went like this.
> select myquerry where myquerry_id = "calculate_customer_total" read the
> cursor, change the cursor to memvar, eval the memvar to get real data into
> say the customer account number, pass pack to the server the statment
>
> Well it worked... not something I was proud of...
>
> Bob Lee
>
>
> ----- Original Message -----
> From: "Ed Leafe" <ed@leafe.com>
> To: "ProFox Email List" <profox (at) leafe D.OT com>
> Sent: Friday, May 30, 2003 12:18 PM
> Subject: Re: A little help with VFP -> SPT
>
>
> > On Friday, May 30, 2003, at 12:03 PM, Stephen Russell wrote:
> >
> > > SP's to me is CODE that is redundant in nature, asked for too often,
> > > and in general deals with many transactions. EOM, EOY, Payroll,
> > > Aging Reports for
> > > AR, AP. Inventory turn over. You need the WHOLE table for the
> > > process,
> > > instead of C/S work where I need all customers starting with 'C' for a
> > > finder list.
> > >
> > > My POV is to stop bandwidth waste, keep the data on the server for
> > > the changes necessary in the process, let the server do what it does
> > > REAL GOOD, notify me when it's done.
> >
> > OK, that makes sense, but there is no need then to pass *any* data to
> > the client in these cases. And it doesn't make sense to do this on the
> > client, since you'll never have the need for all 50 desktops to be
> > running EOM, right? Instead, you only need something on the client to
> > trigger the process on the server.
> >
> > Now whether that process is a SP or something like a Python script on
> > the server that does the processing really doesn't matter. In this
> > case, I'd write the code in Python, install it on the server, and
> > build a way to call the script from my app.
> >
> > ___/
> > /
> > __/
> > /
> > ____/
> > Ed Leafe
> > http://leafe.com/
> > http://opentech.leafe.com
> >
> >
[excessive quoting removed by server]
©2003 Bob Lee |
|
