I have a requirement of getting updated/inserted values in SQL server 2008 using CLR method. I read on net that “trigger is meant for validation also”, But I am not getting how to get the incoming values ( before or after update/insert) to the SQL server using .net assembly System.Data.SqlClient , SqlDataReader method.
Is it posible to get the updated/inserted values using dll ?
Please help me.
I am looking for a password protection method in .net for connecting SQL server.
I have a requirement is to secure passwords from developers.
I know most of people will suggest me to use config file store password and some people say use windows authentication.
But my requirement is quite different, I don’t want to reveal password to developers. If I use it in config file the password will be known to developers. How to deny access to config file for developers and give to access to visual studio to that config file?
If I use Windows authentication there is risk of connecting directly to the database server by installing management studio or some other third party tools. Is there any way that will make windows authentication will work only if access from code?
Because the connection string is just that - a string - the code that developers write needs to be able to access the "raw string" that is sent to SQL as part of the Connection event.
Because their code can access it, so can the developers.
All you can do is give them username / password combinations which are just sufficient to do their job (i.e. can insert, select, maybe update - but not add, edit, or create tables) and if you are still feeling paranoid log everything that user account does.
But even trying to prevent them having access when they clearly are going to need it says "I don't trust them" and that's not good for morale or the culture within the company. You may find it counterproductive in terms of retaining good staff - the ones you can trust...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
There's a very easy method.
1. Use windows domain authentication
2. Run your application (or application pool, if IIS) under a service account. Give that service account the appropriate permissions on the database (which would have to be on a domain machine in this scenario). Don't give the password to your devs, set this up yourself (or whatever Security person you have assigned to account actions).
3. Make sure that dev accounts don't have access to the SQL server if you're worried about them using SSMS.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
All code that is running is running AS THE USER THAT LAUNCHED IT.
If the developers cannot access the content of the config file, neither can Visual Studio nor the application the developers launch in the debugger.
You seem to have only a single environment, production, where you need at least three. You need a developer environment that the developers have enough access to so they can develop the application and the database. You need a test environment that mirrors production so you can test the application and database changes before you put it in production and also test the deployment of the application and database changes. Finally, and obviously, you need a production environment.
In your case, all three of these need to have their own separate database servers with their own connection strings. They don't need to be the same.
But, it comes down to the point where you absolutely need to trust at least two people with the passwords to the production database. They don't have to be developers but they do have to know what they're doing with connection strings. You cannot avoid this.
But, on top of all of this, you and your SQL DBAs, system admins and networking people need to understand security, in SQL, in Windows Server, NTFS, ... to correctly setup every environment and all of the servers and shares to make sure nobody has more permissions than they need to do their jobs.
I am trying to parse a CSV file having two delimiters, first one is a comma(,) second one is a double quote("). So string related looks like "First", "Last", "123 main st",.
Decimals and time is like 120.00, 01/01/2016 1:44:23 PM,.
The issue is when there is a comma in the string field. Like -- "First", "Last", "123 main st","Apple, Inc.","San Francisco".
Initially I tried to load the CSV file using SSIS Package, there is a comments field, which users are to enter comments, as a result the file has data with double quotes in the comments. The package load failed as a result.
The double quotes are no delimiters in the same sense as the column delimiter - they're used to quote strings in order to allow occurrences of the actual delimiter within a string as part of the string. If a CSV-reading code can't deal with that then it's because it's not paying attention to whether a delimiter is within a quoted string or not.
There are several solutions for reading CSV, here's a great one (which will have no trouble with this): A Fast CSV Reader[^]
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
The problem is you're making a trade off. You're giving up the convenience of having a pre-made solution that works for one where you're going to spend a lot of time writing code and testing it, and fixing bugs, and testing it, and testing it some more.
I know of two ways to load CSV with SSIS.
The first way is with an OleDB connection (and the ACE engine), but it doesn't work very well.
The second way is with a Flat File Connection, which works much better and allows you to specify quotes.
Using columns separator that can apear in column data is a bad idea because it complicate reading and it is possible to do otherwise. It become very tricky when a column can contain both column separator and string delimiter, in this case you almost need to write a program dedicated to reading this particular file.
When I generate a CSV file, I use a Tab (chr 9) as a column separator and no " around strings. Since the Tab is only used as column separator, reading is really easy because of the unique usage of the tab.
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
Last Visit: 31-Dec-99 18:00 Last Update: 2-Oct-23 12:38