Payroll Security

Dear all,
I want to use SQL 2005 as back end for payroll software.
If I want the administrator can not see the employee salary, how to use the
built in encryption feature ?
Thanks.
VensiaOne of the ways to do this would to use a trigger on the table that contains
the information. In this CLR Trigger, call the native encryption functions.
Shaun McDonnell

> Dear all,
> I want to use SQL 2005 as back end for payroll software.
> If I want the administrator can not see the employee salary, how to
> use the
> built in encryption feature ?
> Thanks.
> Vensia
>

Pauses in SQL 2000

I am running SQL 2000 SP3 on a Windows 2003 server. I am
having problems with pauses in my application software. I
put a protocol analyzer on the switch and I am getting no
data error but I am getting a large amount of SQL
retries. It this normal? Has anyone seen this problem
before?
Thanks,
Jason Mobley
Technology Director
NWFL Daily NewsRetries sound like client connection issues. What I would do is try and
isolate a client machine, and see if you could load SQL client tools. Then
you could run SQL Client Network Utiltiy and compare it to SQL Server
Network Utility on the server. Sometimes the TCP/IP sockets port gets
changed from the default port of 1433, or firewalls block it. In that case,
the clients will switch from TCP/IP sockets to Named Pipes, or conceivably
keep trying to connect. I would investigat that. Even though Named Pipes
seems to be a default, I've seen a lot of clients out there default to
TCP/IP sockets, especially when going to ODBC Data Sources in control panel
and configuring a SQL Server System DSN (client configuration on the login
credential screen shows you what is being used for connections as well).
Read this article for information on Named Pipes and TCP/IP sockets
http://msdn.microsoft.com/library/d.../>
1a_7fcj.asp
****************************************
***************************
Andy S.
MCSE NT/2000, MCDBA SQL 7/2000
andymcdba1@.NOMORESPAM.yahoo.com
Please remove NOMORESPAM before replying.
Always keep your antivirus and Microsoft software
up to date with the latest definitions and product updates.
Be suspicious of every email attachment, I will never send
or post anything other than the text of a http:// link nor
post the link directly to a file for downloading.
This posting is provided "as is" with no warranties
and confers no rights.
****************************************
***************************
"Jmobley" <anonymous@.discussions.microsoft.com> wrote in message
news:6e1801c3e75a$3c080fa0$a301280a@.phx.gbl...

quote:

---

> I am running SQL 2000 SP3 on a Windows 2003 server. I am
> having problems with pauses in my application software. I
> put a protocol analyzer on the switch and I am getting no
> data error but I am getting a large amount of SQL
> retries. It this normal? Has anyone seen this problem
> before?
> Thanks,
> Jason Mobley
> Technology Director
> NWFL Daily News
>

---

password storage

Hi everybody

I am working on a school project where I am writing a software for course registration. I have different users Students, Faculty, and Administrator. They are allowed to log in using their ID and password. I was wondering how could i store password and userID securly. Should I store it in the individual table or separately?

Any suggestion is appreciated. Also, if somebody has worked on this kind of project, please let me know.

Thanks a lot[I am using SQL 2000.|||You need to use what is known as "one-way" encryption. The good news is that this is simpler than "two-way" encryption where it is must be possible to both encypt and decrypt a text string. In one-way encryption you apply a function to encrypt the string, and then store the encrypted result in your table. When someone submits their password to log in, you apply the same encryption function to their password and then compare it to the encrypted version stored with their personal record. If the two match, you let the dude in.

There are some built-in encryption functions within SQL Server which are simple to use. I think they are called dbencrypt and dbcompare, or something similiar. The disadvantage with these is that they are undocumented functions, and if you upgrade your database to a new version of sql server Microsoft does not guarantee that it will use the same encryption algorythm in future versions. The result (and this has happened in past upgrades...) is that the passwords your users submit no longer match the versions stored in your database. They must all be reset and new ones must be entered.

You can write your own one-way encryption algorythm, or I have one that you can use that is more secure than the one supplied with SQL Server. (The built-in function has been cracked and the solution is available on the internet.)

blindman

Password does not meet Windows policy requirements 2005

I have been given the task to see if our software will work against SQL
Server 2005:-
XP Pro installed on a Virtual PC
SQL Server 2005 Standard Edition Installed
Mixed mode Security
Check policy set to off
Installation of 2005 was successful and no error reported in the logs.
Now the fun started hen attempting to install our software, using the SA
account (we have also created additional SQL logins too but still have the
same problem) it gets as far as creating the various databases but when
attempting to create tables it receives the following error:-
Create Table failed
SQL-DMO error: 15118 [Microsoft][ODBC SQL Server Driver][SQL Server]
Password validation failed.The password does not meet Windows policy
requirements because it is not complex enough
The password we are using meets the criteria for creating passwords and I
have also checked Windows Security Settings and the Passord Policy 'Password
must meet complexity requirements' is disabled
If you need any additional information please let me know.
Many thanks
PaulHi Paul,
make sure that there is o domain policy activated which forces secure
passwords.
HTH, jens Suessmeyer.|||Jens,
Thank you for your reply the domain policy is not currently active
Paul
"Jens" wrote:
> Hi Paul,
> make sure that there is o domain policy activated which forces secure
> passwords.
> HTH, jens Suessmeyer.
>