John,

This thread *does* concern MSDE as delivered for Access 2000, does it not?

If so, then I don't see that there is *any* security or *any* transaction logging in that 'product'.
In fact it is said to include only the "relational engine" and the "storage engine".

Accordingly, about the only "compatability" between MSDE and its parent would be in the SQL statements themselves. Can you see anyone being able to directly 'port' their Access application to *real* SQL Server?
In fact I would say that VFP's SQL is darned near as "compatible" as MSDE is.

I would agree that MS can make marketing hay out of "it is the identical components as SQL Server" but it sure looks differently when doing a bit of thinking about it.

Jim N

>Yes, it does keep a Tx. log. And, I have it on good authority that integrated security is in fact, supported. Based on the website, when you install MSDE, you have the SQL-DMO objects at your disposal. If this is true, then you can define users, roles, etc.
>
>
>>Hi JVP -----
>>
>>I agree. With the need for strong security and transaction logging, a dedicated server database is required regardless of topology. DBFs fall down in that respect. I haven't played with MSDE too mush; does it keep a trnxlog?
>>
>>
>>>OK John, consider this scenario:
>>>
>>>I have a data-set that will never grow beyond 10 mb's. However, the data set contains confidential information and needs inherent security. Also, because of certain requirements, a detailed transaction log needs to be kept.
>>>
>>>Is the data-set small? Yes.
>>>Will DBF's work? No.
>>>
>>>I could have taken this example further to really skew it toward SQL-Server, or some other server RDBMS. Then again, I did'nt have to.
>>>
>>>This is an interesting discussion. Let's keep it going...
>>>
>>>
>>>
>>>>>
>>>If an application is never going to grow beyond a set, reasonable amount of users I was advocating sticking with the good ole DBF format.
>>><<