I planning to use Microsoft Enterprise library 5, for connecting Microsoft Access and perform asynchronous operations. I found that ODBC can be achieved by using GenericDatabase of Microsoft.Practices.EnterpriseLibrary.Data But in that method I am getting a error as "The database type "GenericDatabase" does not support asynchronous operations"
Is it possible to perform asynchronous operations using Microsoft.Practices.EnterpriseLibrary.Data.GenericDatabase ?
If not what are the possible alternatives for me ?
Asynchronous data access is not supported by all ADO.NET data providers. The Database class exposes a Boolean property named SupportsAsync that you can test to check at run time if asynchronous operations are supported. If this property returns false, any asynchronous methods you call will throw an InvalidOperationException. In Enterprise Library 5.0, the only database type that supports asynchronous operation is the SqlDatabase class.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
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
Last Visit: 31-Dec-99 19:00 Last Update: 24-Jan-22 17:19