>I have just played around with using ODBC and the cursor adapter to connect to a backend server (right now i'm using mysql). as mentioned earlier, my main concern is security of the information stored in the database.
>
>my question is: why is a backend server more secure than the foxpro tables if, when accessing using odbc, you have to input the userid and password to gain access and this information is either stored in a configured dsn or in a foxpro program which is easy to read? now, i did try to access using a dsn under a different operating system account, and i didn't have access to it, so i'm assuming that once you log into your client system, you automatically can have access to the server simply by using a previously configured dsn?
>
>hope this makes sense. still learning the terminology here.
>
>thanks.
>
>paul

Paul,
VFP native (and a lot of other xBase like dbase, clipper ...) is file based, 'backends' (anything including VFP could be a backend but here we mean others like SQL server, mySQL, Oracle ...) are service based.
From security point none of them is bulletproof (IOW you could hack into any one of them). However, with xBase series all it gets is a physical access to files. Just open with say notepad and you're in. You can open with say excel and edit data, vice versa. With 'backends' it's not that easy (not meaning it's hard -depends on mileage of the user- but not very much easy).
For security, either for VFP or 'backend' you get help from OS' own security. With VFP it means blocking direct physical access and not something that someone could implement easily. With 'backend' OS security is one of the access layers if you want (for say SQL server it's the recommended one - who recommends? hmmm not finding a direct reference say it's me but it's also in docs believe me, and if not anything else it's the default since SQL 2000:)

OK this is a huge debatable topic so let's concentrate on your question.
"if, when accessing using odbc, you have to input the userid and password to gain access and this information is either stored in a configured dsn or in a foxpro program which is easy to read? now, i did try to access using a dsn under a different operating system account, and i didn't have access to it, so i'm assuming that once you log into your client system, you automatically can have access to the server simply by using a previously configured dsn?"

"you have to input the userid and password" - No. Unfortunately almost all the samples dealing with ODBC connections show that as if it was the recommended way but is not. Using windows authentication you do not put any user id and pwd anywhere for ODBC. Consider these 2 connection strings for SQL server:
"Driver=SQL server;server=servername;User Id=user;Password=pwd"
"Driver=SQL server;server=servername;Integrated Security=SSPI"
latter one doesn't store or use username/password (SSPI stands for "Security Support Provider Interface"). It relies on the fact that anyone who have access to server (not anyone really) has access to database. IOW it's NT security giving the passport. I'm saying, not anyone really, because there is a level on the rights that're granted by default plus SQL server admin could specify which NT/User accounts might access to what. It's a long topic, to keep it simple, with windows authentication mode:
1) You do not specify user id and pwd on any connection string (either via ODBC connection string or DSN configuration).
2) You control NT accounts' rights on your db. (Think of this as a class controlling the permissions)


"i did try to access using a dsn under a different operating system account, and i didn't have access to it, so i'm assuming that once you log into your client system, you automatically can have access to the server simply by using a previously configured dsn?"

As covered as #2, different NT accounts could be assigned different rights from no access to full access (sysadmin can specify many things beyond simple read/write, can execute stored procs, can execute bulk copy etc).

SQL server data is also kept in physical files, NT security is not very unbreakable etc. However think it in the context of average user. S/he wouldn't be able to break into and even if s/he did, it's not that easy to hack the data (vs simple opening with notepad or excel with dbf files).

Try it yourself. On the same computer where you've full access, have both dbf and SQL server files. For a moment forget ODBC and OLEDB and try to read data from both. Compare what it takes:)

Cetin