Jack @ ASP.NET

The restrictions on default values for optional parameters may remind you of the restrictions on const fields or attribute values, and they behave very similarly. In both cases, when the compiler references the value, it copies it directly into the output. The generated IL acts exactly as if your original source code had contained the default value. This means if you ever change the default value without recompiling everything that references it, the old callers will still be using the old default value. To make this concrete, imagine this set of steps:

1. Create a class library  with a class like this:

   public class MyDemo
   {
   	public static void PrintValue(int value = 10)
   	{
   		System.Console.WriteLine(value);
   	}
   }

2. Create a console application (Application.exe) that references the class library:

   public class Program
   {
   	static void Main()
   	{
   		MyDemo.PrintValue();
   	}
   }

3. Run the application—it’ll print 10, predictably.
4. Change the declaration of PrintValue as follows, then recompile just the class library:

   public static void PrintValue(int value = 20)

5. Rerun the application—it’ll still print 10. The value has been compiled directly into the executable.
6. Recompile the application and rerun it—this time it’ll print 20.

This versioning issue can cause bugs that are hard to track down, because all the code looks correct. Essentially, you’re restricted to using genuine constants that should never change as default values for optional parameters. There’s one benefit of this setup: it gives the caller a guarantee that the value it knew about at compile-time is the one that’ll be used. Developers may feel more comfortable with that than with a dynamically computed value, or one that depends on the version of the library used at execution time.

Of course, this also means you can’t use any values that can’t be expressed as constants anyway—you can’t create a method with a default value of “the current time,” for example.

Personal credit, "also known as" personal credit history "or" personal credit history, "which refers to people in dealings with banks, bank loans and repayment behavior in the records. It is the bank’s decision not willing to borrow money, How much to borrow money and lend an important basis for the length of one period. personal credit history is divided into four categories: one is the individual identity, including name, marital and family status, income, occupation, education and so on. Second, the commercial credit records, including personal loans of all commercial banks and repayment records, personal bank card and other relevant records. Third, public information records, including personal tax, to participate in social insurance, to pay utilities, phone, telephone and personal property status and changes in other records. Fourth, there is likely to affect the personal credit situation involving civil, criminal, administrative proceedings and records of administrative punishment in particular. Such as poor credit credit card. Therefore, even if the individual has never had money to bank loans, personal credit records can also be based on assessment of other information personal credit.

Consumers should know how to establish credit line: Early to borrow money, as early as Ericsson. Establishment of a "credit " to borrow from the bank began the beginning. The earlier loan to the earlier establishment of loans in the banking records of individuals for the gradual establishment of "credit" laying the foundation. And the last solution is try to rebuild credit card.

In my last post Call SQLCMD to run SQL script via C#, we know how to call SQLCMD via C#. But in most scenarios, we also need the exit code(%ErrorLevel%) or the sub SQLCMD thread. It is simple, use ‘-b’ in sqlcmd can do this!

So, just add a –b parameter when call the SQLCMD!

Here are more parameters in error reporting,

Usually, we need to call some sql script to update our database in our application(C#), and it is a good way to call SQLCMD to execute the sql scripts. One important reason is that our scripts always contains the GO statement which is is not a Transact-SQL statement; it is a command recognized by the sqlcmd and osql utilities and SQL Server Management Studio Code editor. Since the SQLCMD and SQL Server Management Studio will do the same thing, the scripts edited by SQL Server Management Studio will be 100% supported by SQLCMD.

Here is a block of code to call SQLCMD:

string tmpFile = Path.GetTempFileName();

string argument = string.Format(@" -S {0} -d {1} -i ""{2}"" -o ""{3}""",
    ServerName, DatabaseName, fileName, tmpFile);

// append user/password if not use integrated security
if (!connection.IsIntegratedSecurity)
    argument += string.Format(" -U {0} -P {1}", User, Password);

var process = Process.Start("sqlcmd.exe", argument);
process.StartInfo.UseShellExecute = false;
process.StartInfo.CreateNoWindow = true;
process.Start();
while (true)
{
    // wait for the process exits. The WaitForExit() method doesn't work
    if (process.HasExited)
        break;
    Thread.Sleep(500);
}