>Hi Cetin,
>
>Slow responding here...not much time to look at responses once Dec 22nd hit...a couple follow up questions:
>
>Just curious: I take it below are just functions you have in a procedure file that are available at all times?


Yes, but since I don't like procedure files being hard to manage, I prefer them to exist as separate prg files (like even a few lines of procedure might be a separate file). Mike Yearwood was suggesting this and I was objecting, thinking it is better to have less files but in time, I saw he was right :) Sometimes I have a few procedures in the same file if they are closely coupled. These are all separate prg files (SQLQueryInto.prg for example).


>
>>

>>SQLQueryInto( "select * from myTable where someField = ?", "crsResult", theParameterToSearchFor)
>
>>lnRowsMatchingSomeCriteria = SQLExecuteScalar("select count(*) from myTable where myField = ?", myParameter)
>
>>SQLInsert("MyTable", "field1, field2, field3m field4", 1, "Some char data", "Another one", DateTime())
>
>>SQLNonQuery("Update myTable set myField=? where id=?", m.ValueToset, m.Id) 
>>

>
>What do you mean below "at runtime it is replaced by a CA"? Is that additional code that fires when the form is instantiated to add an object to the DE?


We want to use CA, not simple cursors, right? What I did is to run a small prg in base form class' beforeOpenTables method. It checks what I have in it there, and replaces the usual cursors in DE with their CA counterparts, relieving me from doing that manually. That also means you could drop a native table to DE as you do and at runtime in fact use a CA (thus, one might serve as prototyping while at runtime you are using the production data - SQL or VFP). However, you shouldn't take this as it is good to have tables in there. With C/S it is better not downloading the data (as a helper the "replacer" code utilizes some tags in there which filter the data, rather than downloading the whole table).



>
>>Also, if you have a table in DE (pointing to a VFP table as expected normally), at runtime it is replaced by a CA that points to either VFP or SQL and all this is based on an app wide setting (oApp.DataMode and oApp.DataConnectionString namely).
>
>I am curious how the below SQL string "flips" between the VFP and SQL code - is that done by some other code that removes the code it does not want based upon the app wide setting (oApp.DataMode)?
>


All data related code go through GetSQLText() - say SQLQueryInto(...) calls that and others as well). Its job is to prepare final code based on oApp.DataMode.



>
>>Also I have a GetSQLText() method, that sanitizes the SQL before sent to backend based on what that is (SQL dialects and functions are not the same in all backends). ie:
>>
>>

>>local lcSQL
>>text to m.lcSQL textmerge noshow
>>select *, 
>>   cast(
>>      <SQL>case shippedOn is null then 'Pending' else 'Shipped' end</SQL>
>>      <VFP>iif(isnul(shippedOn), 'Pending', 'Shipped')</VFP> 
>>   as varchar(10) ) as Status
>>from Customer cu
>>inner join Orders ord on cu.CustomerId = ord.CustomerId
>>where orderDate >
>><SQL>dateadd(month, -1, getdate())</SQL>
>><VFP>gomonth(DateTime(), -1)</VFP>
>>end text
>>
>>SQLQueryInto(m.lcSQL, 'crsResult')
>>

>
>On the below, the app is a mix of some SQL commands - for Selects, I always use them (well, mostly all - there are a few legacy lookups done another way but those are easily changed). I use some SQL Inserts - but then a lot is controlled by the framework as I use local views. Mike Yearwood would say that I can change all those views to something else...I will post to him soon.
>
>>It suggests that you should convert most of your data related codes to SQL (SQL-Select, Insert, Update, Delete) and yes it is, but also have xbase support like:
>
>
>Thanks for everything...you must be a fast typer!
>
>Albert