I have tried searching for tutorials and need help being pointed in the right direction.
I am stuck with trying to get the local database to accept data and ensuring my SQL commands are safe. I would also like help for what you would do if creating this application.
Please help. How to put two columns in a combo box (list Box, text box:mad. I work with VS2015, c# and MySql 5.7.
Attached part of the code.
private void comboBox1_Click (object sender, EventArgs e)
myConnectionString = pwput;
conn = new MySql.Data.MySqlClient.MySqlConnection ();
conn.ConnectionString = myConnectionString;
catch (MySqlException ex)
MessageBox.Show ("DO NOT SUCCE TO CONNECT ON SERVER, CLOSE PROGRAM TO TAKE A REPLY");
MessageBox.Show ("NOT ACTIVE SERVER, SUBSCRIBE SERVER PA REPEAT CONNECTING");
if (conn.State! = ConnectionState.Open)
MessageBox.Show ("DO NOT SUCCE TO CONNECT ON SERVER \ r \ n CLOSE PROGRAM TO TAKE READY \ r \ n");
AutoCompleteStringCollection kontoopis = new AutoCompleteStringCollection ();
string wnadidok = "SELECT idkonto, FROM account name";
loadingData = false;
DataTable dtkon = new DataTable ();
MySqlDataAdapter mdkon = new MySqlDataAdapter (wnadidok, conn);
loadingData = true;
comboBox1.DataSource = dtkon;
// which field is shown in the table below
comboBox1.DisplayMember = "idkonto";
comboBox1.ValueMember = "idkonto";
comboBox1.DisplayMember = "title";
comboBox1.ValueMember = "title";
comboBox1.SelectedIndex = -1;
comboBox1.Text = "";
loadingData = false;
We have a device that requires the user to log in. Currently, the usernames/passwords are stored in a table in the database on the device. In the table are also roles such as "Operator" and "Supervisor", and an Active checkbox.
We now have a requirement that if AD is configured/enabled, then use that to validate the user. This opens up some questions.
1) How can I tell in C# if AD is configured/enabled?
2) Is it possible using AD to store and retrieve the roles I mentioned as well as the Active checkbox?
The goal would be to not store this info locally on a device but to have validate and identify the user and device related information from outside the device.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
Role is your concept, AD works with GROUPS and a user is a member of 1 or more groups, a heavy security requirement can be a nightmare. We had to get creative around the name of the groups to support department and role. Typically
The article you describe as "old" has #337 votes. There's a comment with code suggestions in Oct, 2016, which the author acknowledged.
Is it too much to ask that you review more than one article on CP (out of many) ? [^]. Or that you visit StackOverFlow, and sample possibly relevant sources.
"If not you, who ? If not now, when ?" (sometimes attributed to Hillel the Elder)
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
Having a AAA source like LDAP is how things should be done for any non-trival application with securables. It does a few things for you, such as de-obligating the engineer from concerns like identity and role tracking, and makes things grotesquely easier from an operations standpoint. If someone leaves the company, just disable 1 account rather than having to check each application and remove accounts.
While I respect Richard's advocacy of System.DirectoryServices.AccountManagement (S.DS.AM), I've played with the namespace some and, depending on the use case, have found it to be restrictive and slow. There are three namespaces for using AD in three different ways, and each has strengths and weaknesses. S.DS.AM is the newest library, and it has a number of helper functions out of the box and is streamlined a bit, but it interfaces with the MS ADSI interface, which is an entire operational layer that exists at a higher level than LDAP. The base namespace, System.DirectoryServices (S.DS) is less streamlined, but more flexible, but also leverages the ADSI interface.
I generally use System.DirectoryServices.Protocols (S.DS.P) since it doesn't touch ADSI and goes straight through as LDAP. The library is minimalist, so learning to use it can be tricky, but it is several orders of magnitude faster than the alternatives (and I mean hundreds), so if you find yourself working with multiple records it can be a life saver. It also de-couples you from Active Directory by targeting LDAP directly, which can be implemented in a few different ways.