Please help me in designing one of our payroll policies. i have been trying but unable to find any solution.
i have data in 2 tables :
1. attendance (empid, date, hours, leaveallowed)
2. holidays (date,type) (4 types of holidays like national, weekly offs etc)
Policy: if any employee is not present on both days - the day before and after the holiday then leave allowed is false
attendace table contains the records for all employees who are present and i have to add rows for missing dates where leaveallowed will be false (hours will be zero).
eg. if any employee is absent on friday and monday then leaveallowed for saturday and sunday will be false.
i have tried many things but the best i have is following query that uses cross join with holidays table after adding rows for all dates in holidays (holidays table now looks as calendar)
Code:
SELECT DRVD.empid,DRVD.calendardate,DRVD.holidaytype,
attendance.workhours
FROM attendance RIGHT OUTER JOIN
(SELECT * FROM employees CROSS JOIN calendar
WHERE calendardate < getdate()) DRVD
ON attendance.empid=DRVD.empid
AND attendance.workdate=DRVD.calendardate
We are currently trying to make payroll data stored on an SQL server available via a secured web site for our employees. This will allow them to view their direct deposit information by visiting a particular .asp page running on our web site. In order to enable this, we must create a connection to the SQL server. In order to verify the connection, we have created an Access ADP that will allow us to test our connection parameters. Once we can connect in Access we can write a connection string for use in our .asp pages. We believe that the following connection parameters should connect to the SQL server:
Server Name: hsa1.***.com:1433 User Name: payroll-web Password: *** Database: HSA
We have already created the payroll-web user name on the SQL server and given it permissions to access the HSA database running on the SQL server. However, when we create an Access ADP using these settings we receive the following error:
"Test failed because of an error in initializing provider. [DBNETLIB][ConnectionOpen(ParseConnectParams())]Invalid connection."
At this point we are unaware of the cause of this error and have tried several different workarounds, none of which have worked:
Replaced hsa1.***.com:1433 with hsa1.***.com, 1433 Replaced payroll-web and *** with Administrator and *** Removed HSA Selected NT/Challenge Response Security instead of provising a user name and password
Does anyone have any ideas as to (i.) why this error is occuring and (ii.) what we can do to solve it and connect to the SQL Server using an Access ADP? Thanks so much for your help!
Warm Regards,
Kristopher A. Tillery Director of E-Commerce, Harvard Student Agencies
Email: tillery@fas.harvard.edu Phone: +1 603 205 0228 Post: 359 Quincy Mail Center, Cambridge MA Web: http://www.hsa.net
I need to store payroll information (pay rates) in my data warehouse.I've search on field level encryption and most the stuff i find is forpasswords, I.E. not reversable. I need to protect the payrate fieldfrom dba's and sa's, but I need to allow the authorized users to seethe contents.Any ideas? Does 2005 handle this?I don't have a web app, per se, that access's this information. howeverI am using Cognos' Report Net.thanks in advanceRob
Can it possible of taking full dump db backup of Logshipping server [Secondary Server.] Or any other way {DTS} on Secondary server, to update third server on daily basis.
please co-operate me on this issue Thanx in advance
What is the best way to disable using the Windows policy requirements when creating a new login?
example: I'm trying to create a login and the password doesn't meet the windows policy requirements. The easy thing to do would be to create a strong password. This isn't an option at the moment. I need to disable this so I can create new users that dont have strong passwords.
So, for example, if you have a linkedserver to a database that happens to be on the same server as the querying thread, it fails with the message 'context in use'.
The answer from the previous thread was, don't use linked servers when the database is on the same server.
However,
The enviornment in our production system is fairly dynamic -- operations can be expected to move databases around in response to load balancing issues. We were counting on linked servers to make certain (non-performance sensitive) queries without regard to where a given database was located. Accepting that we have to make an exception case where the database lives on the same server means we'll have to have two sets of queries for every case this happens.
Something like
(pseudocode)
If server of linkedserver <> @@server
Insert into table....
Exec linkedserver.database.dbo.sproc
Else
Insert Into Table
exec database.dbo.sproc
(end pseudocode)
This seems pretty kludgy to me -- any suggestions on how to better manage this situation?
Hi all,We recently started to receive complaints about our install project notworking and giving and shitload of error messages related to SQL. Welater found out that the problem was the users we were trying to bindto we're not created because of the domain password policy featureimplemented into SQL Server 2005.After much dabbling around the SQL scripts that created the databasestructure, we came to the conclusion that only this piece of code couldcorrect our problem :CREATE LOGIN mynewuser WITH PASSWORD = '', CHECK_POLICY = OFF,CHECK_EXPIRATION = OFFThis runs perfectly fine on SQL2005, but not on SQL2000. We have beensearching for a way to have code in SQL files executed on install thatdoesn't fail to compile when run against the server and that willbypass the password policy in case it's a SQL Server 2005...Right now we are testing a feature available in MSI that can filterscripts not matching a database version, but the problem with this, isthat we are missing a lot of features that InstallShield has. In short,we need Help to fix this issue and be able to continue withdevelopment.In hopes to receive a a prompt anwser
We run a few shared hosting servers in the UK, now we used to run mssql 2000 and moved to 2005 in december 2005.
Microsoft SQL 2005 9.00.1399.06 Microsoft SQL Server Management Studio 9.00.1399.00 Microsoft Analysis Services Client Tools 2005.090.1399.00 Microsoft Data Access Components (MDAC) 2000.086.1830.00 (srv03_sp1_rtm.050324-1447) Microsoft MSXML 2.6 3.0 6.0 Microsoft Internet Explorer 6.0.3790.1830 Microsoft .NET Framework 2.0.50727.42 Operating System 5.2.3790
We were in the process of improving security on some of our new servers, in the windows password policies settings we enabled the following minimum password length = 6 characters Password must meet complexity requirments = enabled
sql 2005 authentification was set in mixed mode, but we have tried windows authentification only as well.
Now when you try and add a new user even if the password meets all requirments you get an error password is to short etc, we used sql managment studio both manually creating a user and scripting with sql, both with the same result.
In the shared hosting environment we need passwords to be secure, the only way we can get sql users to be created is to disable windows password policies which causes security problems.
We would prefer to use sql authentification not windows but even when we use sql authent it still seems to use the windows password policy and the same error occurs
I am installing SQL Server 2005 Express as part of my setup. On Windows 2003 Servers with password policy enabled, the SQL Server 2005 Express installation fails. Here is the error I am getting - "the sa password must meet SQL Server password policy requirements. For strong password guidelines, see Authentication Mode, in SQL Server Books Online.". If I disable the password policy, the SQL Server 2005 Express installation is OK.
Is there a parameter that I can pass to the command line to get around this?
I have a 3 node cluster running windows 2003 x64 sp1 and SQL Server 2005 version 9.00.2153. My problem is the following...
This Saturday I migrated a web application's database to this server. After restoring the database I created the sql login for the service account, set the password and disabled the password policy for this login. I then ran sp_change_users_login to attach the already existing db user with the same name to the login. I changed the connection string for the application, tested the application connectivity and functionality then detatched the old database on the old server. Everything went like clockwork, no problems at all.
Come Monday morning at 8:35 I started getting alerts that the web site was down. I tested the site and sure enough it was down. I then attempted to connect to the database server using the login that was created for the app and the connection failed. I logged in with my ID and got in fine. Nothing showing to be wrong with the DB, I checked the new login and somehow the "Enable Password Policy" had been set for the new login. I disabled it and still no connection. I went to the database and checked the DB user and somehow the link between it and the login no longer existed. I reran the sp_change_users_login and restested the web site and verified that that web site was back online.
My question is this, is there any stored proc that resets these values back to default for some reason, a series of events that might revert the "Enable Password Policiy" to the default for a login, or is there a particular domain level operation that might occur such as Security Polcies that would affect these settings in SQL?
No one else was on the machine when I went to check it out at 8:40 so it has left me puzzled.
What are the exact requirements implied by the sql 2005 option:
"Password Must Meet Complexity Requirements "
TIA,
Barkingdog
P.S. I found this one:
-Cannot contain all or part of the username -Must be at least 6 characters long -Contain 3 of the 4 following character groups - A to Z - a to z - 0 to 9 - Special Characters i.e. ! ^ $ *
and I have also found
"At least 7 characters in length"
Combines letters. numbners, and symbolds
Is not a dicitonary word, name of a command, person's name or user's account name
I've legacy code that requires a blank password for a SQL Server login. This works fine on 2000 or 7.
How can you allow blank passwords on SQL Server 2005 without changing the windows policy? Is there a stored procedure to do this? I know you can now use CREATE LOGIN and set CHECK_POLICY to no on SQL 2005 when creating logins, but this needs to run on SQL Server 7/2000 and so its using sp_addlogin. (NB: I can't easily change the legacy code to work conditionally on SQL Server 2005)
Hi, How programing add new <CodeGroup> element to SQL Server Reporting Services policy configuration file "rssrvpolicy.config"(location path:"C:Program FilesMicrosoft SQL ServerMSSQLReporting ServicesReportServer")???
I am building a winforms .net 3.5 application which connects to a SQL Server 2005 database with SQL server authentication. Is it possible to access the SQL Server password policy and expiration through the .NET 3.5 framework? I would like add the following functionality to my login form:
Ensure passwords meet policy standard.
Prompt a user to change their password when it is due to expire in 5 days or less. Thanks in advance.
I have a policy table which has policyNumbers and createDate. I need to retrieve all rows where createDate is between 2 dates and there is more than 1 row with the same policy number. I cannot figure out the SQL to return all policy number rows if there are more than 1 row with the policy. Most policies number will be in the table once. I need the others.
AppDomain 446 (A.dbo[runtime].477) unloaded. AppDomain 446 (A.dbo[runtime].477) is marked for unload due to memory pressure. Error: 6532, Severity: 16, State: 48. .NET Framework execution was aborted by escalation policy because of out of memory. I€™m getting this problem on server €œA€? when I restore a backup that is located on a drive on server €œA€? to server €œB€?. The drive isn€™t actually on server €œA€? it is on an EMC but is mapped to server €œA€?. So, I guess server €œA€? is acting as a file server for the file. Server €œA€? is an x64 bit server with 32 GB of Ram. It has SQL 2005 Enterprise Edition build 9.00.3042.00. Min Memory is set to 2 GB and Max is set to 28 GB. SQL service is running under a windows account with €œLock pages in Memory€? set. From what I€™ve read this was a problem but I thought SP2 fixed it. Any ideas? Thanks.
Using SQL Server 2005 SP2 std edition on Windows 2003 R2 SP2 x64 std edition I'm allowed to break the password policy.
To reproduce this behaviour as a system administrator run...
create login testuser with password='p'
This creates a login with the default of POLICY enabled ('Enforce Password Policy' check box is checked). OK, so may be system administrator is allowed to break the policy but now login as testuser and run
alter login testuser with password='t' old_password='p'
This succeeds despite obviously breaking the policy.
Surely this can't be right, I must be doing something wrong.
I have a SQL CLR used to read a XML file, it works fine when the file is smaller, but will give me this error if the file if bigger i.e. more than 10M.
Msg 6532, Level 16, State 49, Line 2
.NET Framework execution was aborted by escalation policy because of out of memory.
System.InvalidOperationException: Data access is not allowed in this context. Either the context is a function or method not marked with DataAccessKind.Read or SystemDataAccessKind.Read, is a callback to obtain data from FillRow method of a Table Valued Function, or is a UDT validation method.
System.InvalidOperationException:
at System.Data.SqlServer.Internal.ClrLevelContext.CheckSqlAccessReturnCode(SqlAccessApiReturnCode eRc)
at System.Data.SqlServer.Internal.ClrLevelContext.GetDatabase(SmiEventSink sink, Int32* pcbLen, IntPtr* ppwsName)
at Microsoft.SqlServer.Server.InProcConnection.GetCurrentDatabase(SmiEventSink eventSink)
at System.Data.SqlClient.SqlInternalConnectionSmi.Activate()
at System.Data.SqlClient.SqlConnectionFactory.GetContextConnection(SqlConnectionString options, Object providerInfo, DbConnection owningConnection)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at BuildDirect.SQLCLR.CLRErrorHandler.RaiseNewCLRError(Int32 errorid, String errormsg)
at BuildDirect.SQLCLR.CLRErrorHandler.ReportCLRError(String location, String errormsg)
at BuildDirect.SQLCLR.CLRErrorHandler.ReportCLRError(String location, Exception ex)
at BuildDirect.SQLCLR.HTTPRequest.uCLRGetHTTPResponse(String url)
I have configured DB Mail in our SQL Server Management Studio. But I am getting the following Error. Also I am getting Same Error while doing SSRS Report Subscription via mail. (Same Server).
Error Message The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 4 (2015-07-21T04:22:24). Exception Message: Cannot send mails to mail server. (Transaction failed. The server response was: Mail from analytics@xyz.com rejected for policy reasons.). )
For your additional info: In SSIS I can able to send email using Mail Task.
I have a user, who is trying log into the server, but everytime he gets this error saying something about the Group policy denies him access.
This user needs access and i'm trying to understand how to grant it to him.
I have been looking into how i can access the group policy editor, but the farthest i can get is the Local group policy editor. How do i make sure this specific user has access?
Is there any way to enforce table references in stored procedures? For Example, we have stored procedures with a ton of different formats, "dbo.table", "table", "db.dbo.table", etc. Can we make it so that for every stored procedure, the reference must be at least "dbo.table"?
I have been searching for a means to change the System Failure Error Check policy that comes as part of the Best Practice policies. I want to look back 24 hours. The WQL query shipped with the policy doesn't have a WHERE clause component that looks at TimeGenerated. That query looks like:
IsNull(ExecuteWql('Numeric', 'rootCIMV2', 'select EventCode from Win32_NTLogEvent where EventCode=6008 and Logfile="System"'), 0)
After searching for an example of how to do this and not finding any that are specific to PBM, I decided to fall back to a very basic approach - use wbemtest.exe to try out where clause additions and see how they work, then plug the result into the policy and see if it works. As a start, I tried the following query using wbemtest.exe:
select Event Code from Win32_NTLogEvent where EventCode = 6008 and Logfile = 'System' and TimeGenerated > '20130101010000.000000–000'
This works great in wbemtest.exe. My next step was to plug this into the policy condition expression as follows: IsNull(ExecuteWql ('Numeric', 'rootCIMV2', 'select EventCode from Win32_NTLogEvent where EventCode=6008 and Logfile="System" and TimeGenerated > "20130101010000.000000–000"'), 0)
When I try to manually evaluate this policy in SSMS, I receive an "Invalid Query" error message.I assume that SWbemDateTime isn't available to use inside Policy Based Management policies. All the examples of how to handle the kind of dynamic date creation I have seen are for use in PowerShell, VBScript, or SSIS. I've played with using DateDiff, DateAdd, and GetDate inside the query string, with no success.
Why does the ExecuteWql above fail?Is it at all possible to dynamically generate a datetime (say, 24 hours ago) as part of the query string parameter of the ExecuteWql call?What might that look like?
I have a complicated question that involves the password policy defined within Windows Server 2003 and how it is used in Microsoft SQL Server 2005. I recently installed windows server 2003 on my development system. I am a person that prefers to develop in the same OS that our application runs in production. After installing 2003, then a Domain administrator added my machine to our corporate domain. Now, I cannot change the local password policy to allow a simple password. I believe this is due to policy inheriting from the domain that the machine belongs to.
This ties back into SQL Server 2005 because installing sql server on a Server 2003 causes SQL Server 2005 to follow the password policies defined at the OS level. This breaks our application in a subtle way in that we create login accounts for new client databases with random password. Because the password is random it sometimes conforms to the policy and sometimes not.
In production environments, the password policies are configured differently. So I need to one of the following options:
-change the group policy/inherited policy on my machine to not inherity from the domain I joined (prefered solution but don't know HOW)
-change SQL Server to not use OS password policy
-change code to use CREATE LOGIN statement with CHECK_POLICY=OFF or change password generation code to use a stronger password. (don't want to do this as the code change is only accomodating non-production environments)
If someone has a better place to post this question, I would sure appreciate it.
I am receiving the following error message when attempting to create a new SQL Authenticated login id.
Password validation failed. The password does not meet the requirements of the password filter DLL. (Microsoft SQL Server, Error: 15119)
I have four servers all running SQL Server 2005 SP2 on Windows 2003 Ent. SP1. Of the four servers, only one received the above error message using the same TSQL below.
CREATE LOGIN TEST_LOGIN WITH PASSWORD = 'pvif9dal' MUST_CHANGE, CHECK_EXPIRATION = ON
All four servers are in the same domain, which if I understand correctly, the password policies are therefore inherited at the OS level by the domain. The password being used is within the password policies of the domain.
