Friday, March 30, 2012
pervasive SQL V8 vs SQL server 2000
My manager wants a in-depth analysis comparing pervasive SQL V8 to SQL server 2000.
I have searched the web extensively but information is scarce.
Are there any articles or case studies that do an indepth analysis comparing both databases? Can someone please help me. It would be greatly appreciated.please don't cross-post
if you do not wish your thread to be in the pervasive forum, let me know if you wish it to be moved to the sql server (or any other) forum|||Here's a white paper that talks about cost of ownership of PSQL:
http://www.pervasive.com/download_Check.asp?download=/documentation/whitepapers/pdf/Aberdeen_v8.pdf
You're probably not going to find too many "in depth analysis" comparing the two databases because for the most part they don't occupy the same market.
Pervasive is marketed more for mid sized businesses where SQL Server is marketed toward the enterprise. That doesn't mean that PSQL can't hold it's own in the enterprise. I've seen PSQL running in an environment where there were 1500 + concurrent users hitting the database. I know that some very large companies use PSQL. For example, Fry's electronics uses PSQL for it's Point of Sale system. Here's a link with a "Wall of Fame" for PSQL references.
http://www.pervasive.com/lp/walloffame2/?referer=/psql/index.asp?promo=
Monday, March 12, 2012
permissions for developers not working after 2005 upgrade
Prior to our move to 2005...permissions were granted to developers by adding them to the following fixed database roles...db_ddladmin, db_datareader, db_datawriter, and db_securityadmin. They created their objects using 'dbo' as the owner.
After upgrading to 2005, suddently they are having difficulty accessing their objects with this same security. Do they need permissions on the dbo schema?
Can you please elaborate on the access difficulty? Are you encountering errors and, if yes, what are those errors? It would help if you could give us an example of some action that used to work and now doesn't, and of what is the system response in this case.
Thanks
Laurentiu
They are making a connection through Visual Studio using the MS OLE DB Provider for SQL Server with their domain account and receiving the following error...
SELECT permission denied on object 'Contact_Info', database 'GetLean', schema 'dbo'.
|||Could you check what is the current execution context at the time when this error is obtained? You can use Profiler to figure out what is the current execution context.
There are two possibilities:
(1) current execution context is not a member of db_datareader, so you do not have SELECT permission.
(2) current execution context is explicitly denied SELECT permission on the Contact_Info table.
If you determine the current execution context, then you can check whether it's a member of db_datareader by looking at the sys.database_role_members catalog. You can check for the SELECT permission being denied by looking at the sys.database_permissions catalog.
Thanks
Laurentiu
They are a member of the db_datareader, db_datawriter, db_ddladmin, and db_securityadmin roles. There are no permissions explicitly denied in this database.
Even though they have db_datareader, db_datawriter, db_ddladmin, and db_securityadmin rights....must I still assign them to the dbo schema?
|||db_datareader grants select on the entire database, hence on the dbo schema as well (http://msdn2.microsoft.com/en-us/library/ms189612.aspx). You don't need to do a special permission grant for the dbo schema.
Can you try a little experiment? Create a test table in the dbo schema and then verify if those members of db_datareader can access it. Also, create a separate schema and a table in it and see if there is the same behavior for it as for the dbo schema.
Also, does this happen for all those developers or only for some? If some of them were added to db_denydatareader role, then that would prevent them from selecting from anything. Are they members of other roles than those four that you mentioned?
Thanks
Laurentiu
It turned out not to be a DBA problem. Sorry, should have posted the resolution earlier.
It turned out to be a developer issue...a combination of failing to practice current standards and inexperience with Visual Studio. Aargh!
Permissions error while upgrading to SP2 CTP...
I have a request from one of our researchers to upgrade to CTP SP2. I am getting the error message:
MSP Error: 29506 SQL Server Setup failed to modify security permissions on file C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ for user Administrator. To proceed, verify that the account and domain running SQL Server Setup exist, that the account running SQL Server Setup has administrator privileges, and that exists on the destination drive.
I added server\administrators - full control to the permissions of \Data\, but it still does not work.
Has anyone else ran into this, and how do I fix it?
Thanks,
Alainna
Error 29506. SQL Server Setup failed to modify security permissions on file E:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ for user administrator.
The problem is that there exists a file in this Data directory that the user running SP1 does not have permissions to modify. The workaround is to figure out which file this is (typically a user created DB or some backup program files) and to temporarily assign permission to that file(s). You can revert back to the intended permissions after running SP1.
Thanks,
Sam Lester (MSFT)
Thank you, that worked. I have no idea why I didn't check the files before posting, but thank you!
- Alainna