|
 good advice!
Craigslist Troll: litaly@comcast.net
"I have a theory that the truth is never told during the nine-to-five hours. "
— Hunter S. Thompson
|
|
|
|
|
Hi
I am having trouble building my database connection string, i have to read the server name, db, un, and password from an INI file (dont ask)
This is no problem, but im having trouble using these values to build my connection string
currently im getting the error
A field initializer cannont reference the nonstatic field, method or property
my knowledge of C# is basic to say the least, can anyone point me in the correct diretion or help at all?
thanks
Simon
Code Below
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
using System.Data.SqlClient;
using System.IO;
using System.Text;
using System.Net;
using System.Xml;
using System.Runtime.InteropServices;
namespace WebService1
{
public class Service1 : System.Web.Services.WebService
{
string con;
string ini_path;
string tc_server="";
string tc_database="";
string tc_un="";
string tc_pwd="";
string tc_server_str="";
public Service1()
{
InitializeComponent();
ReadIniSettings();
con=CreateConnectionString();
}
SqlConnection myConnectionCP2 = new SqlConnection(con);
#region Component Designer generated code
private IContainer components = null;
private void InitializeComponent()
{
}
protected override void Dispose( bool disposing )
{
if(disposing && components != null)
{
components.Dispose();
}
base.Dispose(disposing);
}
#endregion
void ReadIniSettings()
{
ini_path="F:\\Web\\tr\\htdocs\\cpbl4\\";
tc_server = IniFile.ReadValue(ini_path,"TC","Server");
tc_database=IniFile.ReadValue(ini_path,"TC","Database");
tc_un=IniFile.ReadValue(ini_path,"TC","UN");
tc_pwd=IniFile.ReadValue(ini_path,"TC","Pwd");
}
string CreateConnectionString()
{
tc_server_str=SQLConn.CreateConnStr(tc_server,tc_un,tc_pwd,tc_database);
return tc_server_str;
}
}
public class IniFile
{
[DllImport("kernel32")]
private static extern long WritePrivateProfileString(string section,string key, string val, string filePath);
[DllImport("kernel32")]
private static extern int GetPrivateProfileString(string section,string key, string def, StringBuilder retVal,int size, string filePath);
public static void WriteValue(string path, string Section, string Key, string Value)
{
WritePrivateProfileString(Section, Key, Value, path);
}
public static string ReadValue(string path, string Section, string Key)
{
StringBuilder temp = new StringBuilder(255);
int i = GetPrivateProfileString(Section, Key, "", temp, 255, path);
return temp.ToString();
}
}
public class SQLConn
{
public static string CreateConnStr(string server, string un, string pwd, string db)
{
string connStr = "server="+server+";max pool size = 7500;uid="+un+";pwd="+pwd+";database="+db+";Connect Timeout=200;";
return connStr;
}
}
}
|
|
|
|
|
Probably this line: SqlConnection myConnectionCP2 = new SqlConnection(con);
You're trying to create the SQL connection in a field initializer... Not a good thing. That should be initialized inside the constructor (Or inside another function).
|
|
|
|
|
This is the offending line:
SqlConnection myConnectionCP2 = new SqlConnection(con); Basically, you are using the value of one field while attempting to initialise another outside a method. This is not allowed - after all, what value is it? What you need to do is create the SqlConnection object, and then initialise it inside a method (although, in your example, you aren't using it anywhere).
|
|
|
|
|
The error is being generated on this line;
si_69 wrote:
which appears at present after the block shown below, with a bit of jiggery pokery, move the object declaration and the initilisation so you end up with the code refactored to;
SqlConnection myConnectionCP2;
public Service1()
{
InitializeComponent();
ReadIniSettings();
con=CreateConnectionString();
myConnectionCP2 = new SqlConnection(con);
}
That should hopefully fix the problem
|
|
|
|
|
compilers usually produce messages including filenames and line numbers. Use them to your advantage, and make sure your IDE always shows line numbers in source editor windows. For Visual Studio, check menu Tools/Options/Text Editor/All Languages/General: "Display Line Numbers".
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Let's not forget that double clicking the error should take you to the exact line.
|
|
|
|
|
When using VS and all happens to be well, which could be a stretch.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
guys;
I was exminning some code and i found this:
try
{
try
{
...
}
finally
{
...
}
}
catch
{
throw;
}
I am wondering if this is legal. I mean catch anything and trow anything;
or maybe it's usefull for something. because the developer who write this code is someone i believe he is an expert.
Thank you;
Help people,so poeple can help you.
|
|
|
|
|
Guy ( or girl .. dunno )
A try is always followed by a catch section, hence the name try.catch block.
The sample you provided is legal, however I would add an additional catch block in case anything goes wrong in the second try section.
try
{
try
{
...
}
catch
{
}
finally
{
...
}
}
catch
{
throw;
}
|
|
|
|
|
Rick van Woudenberg wrote: A try is always followed by a catch section, hence the name try.catch block.
Incorrect. A try-finally construct is perfectly legal. It is only when a try block is followed by a catch block that they are called a try-catch construct.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
.. euhmm .. debatable I guess. Technically speaking you're right, I agree. But what's the use of a try block without a catch block. The try block contains the guarded code that may cause the exception. The block is executed until an exception is thrown or it is completed successfully. The catch clause can be used without arguments, in which case it catches any type of exception, and referred to as the general catch clause. It can also take an object argument derived from System.Exception, in which case it handles a specific exception. So, keeping all that in mind, I'm hard to convince why you'd want two or more try clauses with just one catch clause, as each try block is examined in order of importance and thus handled by the same catch clause.
.. or have I completely lost my mind again.
|
|
|
|
|
Rick van Woudenberg wrote: But what's the use of a try block without a catch block.
To ensure that the exception gets thrown up the chain, AND some critical piece of code gets executed. Consider this example:
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
}
finally
{
if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
}
}BTW, try/finally is exactly how the using statement is implemented for auto-disposable behaviour.
|
|
|
|
|
Pete,
Good point. I guess you're sample is way better than I used to do it. ( see code below ). Other than the obvious thread freezing and just the fact that handling exceptions are 'expensive'.
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
connection.Open();
}
catch
{
MessageBox.Show("Connecting to the database failed..");
}
if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
}
|
|
|
|
|
That code example made me shudder.
Separation of concerns; Is the concern database access or User notification, because it sure as hell shouldnt be both.
|
|
|
|
|
Well, as far as I'm concerned both would be nice. Sure, the connection to the database has priority over user notification, however when something stuffs up, I generally let the user know. In that particular case I would do something like :
private void DoSomething()
{
SqlConnection connection = null;
try
{
connection = new SqlConnection();
connection.Open();
}
catch(SqlException ex)
{
MessageBox.Show(ex.ToString();
}
finally
{
if (connection.ConnectionState == ConnectionState.Open)
connection.Close();
}
}
Then you actually have both of two worlds. However, that puts us right back to the essence of this discussion. Having a catch clause in a method is not something to be ashamed of, though I get the feeling that many developers think that way.
|
|
|
|
|
ahhh, no no no.
If your UI code is mixed with your database access code; you're doing it wrong
If you show Exception messages unsanitized to your users; you're doing it wrong
|
|
|
|
|
Totally agreed on the first point. But regarding the second, he did mention that he might put something else there.
I tend to have something which shows them the exception trace in the critical exception handler, because if there is a serious bug, you (the developer) want that information to fix it. In the case of a database connection failure, though, definitely not, because most of those reasons are not because your software is broken.
|
|
|
|
|
BobJanova wrote: you (the developer) want that information to fix it
And therein is the point. I want it, but I dont EVER want a user to see it. This is what the Windows Event Log (or, perhaps another type of log) is for.
You never have a reason to show a user an unsanitized exception message (caveat: they're programmers and can actually act on the information). There is the potential to give away sensitive information if you do so.
|
|
|
|
|
J4amieC wrote: This is what the Windows Event Log (or, perhaps another type of log) is for.
Or to put it another way - that's what log4net is for. 
|
|
|
|
|
I totally agree with you, and I would never show an exception to a user. Hence the
, but I still think that you should at least say something when anything important messes up, like .. euhh .. a database connection that fails ?
I don't think it's wise to redirect general user messages that could be caused by an exception to the windows logs. Not very user friendly.
|
|
|
|
|
J4amieC wrote: If your UI code is mixed with your database access code; you're doing it
wrong
If you show Exception messages unsanitized to your users;
you're doing it wrong
Ahhh, no. It depends upon the scope of the problem you're trying to solve. If this is a 1,000 line utility app that you're the only user for, this might be perfectly appropriate. If it's a 200,000 line client for a LOB app, then you might have issues.
Software Zen: delete this;
|
|
|
|
|
If you're in a helper layer such as a DAL then you don't want to add any code that will interact with the user, however you may want to do clean up before the exception is thrown up the chain to a level where the exception can be dealt with by the user. Equally what's the difference between the original example and the following?
Private Sub ExceptionMethod()
Try
DoExceptionCode()
Finally
DoCleanup()
End Try
End Sub
Private Sub ExceptionHandlerCode()
Try
ExceptionMethod()
Catch ex As Exception
ExceptionHandlerHere()
End Try
End Sub
|
|
|
|
|
Arrgggh - my eyes. The horror. Case insensitive code in our lovely curly bracketed case sensitive world.
|
|
|
|
|
Sorry, I'll use Smalltalk next time.
More seriously I had a vb editor open so it was just quicker to type it in there with the auto complete than to start up a new c# editor for the example (formatting purposes)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
