C# transfer data from an another form via MySQL

Directly accessing the control on another form isn't the right way.

If the form is a modal dialog then you can expose properties that the caller can set before showing the dialog. Similarly there can be properties to get the results of the dialog (if it's not a simple yes/no confirmation dialog).

If you've ever used the OpenFileDialog, this is a good example of how it should be set up to pass data to and from your form. (This example is taken from the OpenFileDialog documentation.)

    openFileDialog.InitialDirectory = "c:\\";
    openFileDialog.Filter = "txt files (.txt)|.txt|All files (.)|.";
    openFileDialog.FilterIndex = 2;
    openFileDialog.RestoreDirectory = true;
    if (openFileDialog.ShowDialog() == DialogResult.OK) {
        // Get the path of specified file
        string filePath = openFileDialog.FileName;
        string content = File.ReadAllText(filePath);
        // etc...

Here we have properties like InitialDirectory and Filter that we pass to the dialog (or form in your case) and the dialog is directly responsible for setting up its own controls. You don't have to know if it's using a ComboBox or something else, you just specify the data it needs.

Similarly when the dialog resolves, it exposes a property FileName that you can use to retrieve the file that it wants to open. (It also exposes FileNames which is an array of filenames if you want to open multiples. You get the idea.)

For simple yes/no results, you can use the result of ShowDialog which can return an OK or Cancel kind of result that doesn't require a whole property to set up. This is also how you know whether the user hit Cancel and that you shouldn't proceed on to DBConnect(); (Note the if statement in the code example I provided. It's always best to check the result of ShowDialog.)

The MySqlCommand.Parameters.AddWithValue method in combination with @foo parameters in a SQL statement guard against SQL injection. I think more generally, this is known as a prepared statement.

Typically we separate data access logic from UI logic. The biggest architectural issue I see is referencing anything from the UI layer in your data access code. I would put that code in its own class, and pass data transfer objects or straight parameters.

There are four things I find useful to always separate unless I have a good reason not to:

• User interface/display logic.
• User input validation (although this often has some dependency on the UI).
• Business logic - the core logic enforcing business rules without regard to data storage or user interface.
• Data access/storage logic.

"Is directly accessing and passing UI controls (f2.textBox1.Text = ...) between forms considered a bad practice?"

Objectively yes.

Luckily enough, WinForms has all the tools, so you don't need to do that.

For example: you can separate View and Model by using Data Binding. You then would simply point to the same model that is displayed in several forms or dialogs by binding to it.

For your reference and further information: https://learn.microsoft.com/dotnet/desktop/winforms/data/overview