>Cetin:
>
>Stored procedures are not available yet on the stable version of mysql. however, since it is only a backend server, does it not simply hold the data with Foxpro doing everything else? maybe i'm not following what it does. what i want it to do is provide additional security (which both mysql and sql server accomplish) while keeping everything else the same (ie using foxpro forms, reports, stored procedures, etc.).
>
>as i'm writing this, i'm still thinking about why this is important, but maybe since foxpro isn't holding the data anymore but obtaining it from one of these servers, any change to the data won't trigger an event in foxpro b/c it doesn't have it. therefore, if i need stored procedures, it will have to be in the native database. is this correct?
>
>thanks.
>
>paul

Paul,
Stored procedures execute on the server where data reside and they're part of database (so your assumption "if i need stored procedures, it will have to be in the native database" is correct.
"Stored Procedures" (let's say SP in short) are not a must but there are plenty of reasons to use them. These topics are huge and wouldn't fit in here. Just to make you think about it:
Consider you'd calculate balance of a customer, and you've plenty of tables related with a customer. You might do this (in pseuodocode):

procedure GetCustomerBalance(customerID)
select CustomerData From Table1
select CustomerData From Table2
select CustomerData From Table3
select CustomerData From TableN

do some calculation
return resultAsValueOrTable

This procedure might be part of your app. It might be part of your database as an SP. Here sample is only doing selects so importance of SP is somewhat shadowed but still can show it's important at least for 2 reasons:
1) Performance (I won't go into details-simply it doesn't need a recompilation per call)
2) If it's in your app then it's 'hardcoded'. If data structure needs a change affecting the procedure you need to do the change in your app and redeploy. If part of database, app stays as is. You can deliver say only a 'stored procedure' to a client using that DB.

and couldn't resist to add:
When you work with SQL server or another backend you'd use at some point 'batch of commands' and a 'batch of commands' is a program - not technically an SP but functionally it's an SP.
PS: I suggest using SPs and less known/used UDF -user defined functions- with SQL server but that doesn't mean you should do everything with SPs. ie:I had few places where directly getting plain data and doing processing on client was better.
Cetin