I forgot all about "integrated" security for a DBV. Maybe the security could be integrated at the DBC level, though.

For an app I'm doing right now, I have columns called iAccessR and iAccessW, Integer column types that default to 0 (anyone can read and write to this row). I also have a mapping table of NT Local Groups-to-Integers. Whenever a SQL-Update is applied, I check the Local Group membership to get the Integer value, and if iAccessW is > the user's integer then that row gets skipped. Same kind of work on a SQL-Delete and SQL-Insert. The downside to it is that users can only touch data from a stored procedure, because I have to do all that coding for security.

Maybe in VFP7+, anytime you create a DBC there is also a .DBS/.DBT file attached (why not, we already have .DBC/.DCT/.DCX?) which is really just a table and index that has security info in it, you can put local group info in there to have row-level security or something.

I'd rather have that than a >2gb limit, now that I think about it. I have never actually crossed over 2gb, but I run into security needs every day.


As far as the deleted thing goes, I gave up on that flag, and just add an iDeleted column and 0 is not deleted and 1 is deleted. It's portable across all other databases, and I think not using the VFP deleted flag at all and having Set Deleted Off is "always faster no matter the table size" I think (had to put it in quotes to emphasize I really am not sure).

How do you define a "clustered index"? I'm not sure I know what you mean.




>>
>>I see the < g > after your comment, but aside from the 2gig limit and the thorough logging of SQL Server it doesn't seem that unrealistic to me *IF* there's a will.
>>Adding NULLs support wasn't a trivial step by any means, yet they pilled it off! Adding improved security (possibly including encryption with the processing power now available), adding real deletion (or at least the option to IGNORE (tagged as) deleted records), allowing multiple-field (no operators) indexes, allowing variable length fields should all be far more easily doable than NULLs was. We sort of can do a "clustered index" today on our own, and maybe that's good enough for us.
>>There are no doubt lots of other things to consider, but these things would be a damned good start.
>>
>>I initially thought, when I first read this idea, that it might be acceptable to have this "outside" of regular rushmore-capable VFP, but then I said to myself 'but then it wouldn't be *VFP* so I dropped that reply.
>>
>>Cheers,
>>
>>JimN
>
>Then what would we need SQL Server for? <g> again.