|
I hear that AddWithValue is kinda safer, but I rarely use it because of the way I do things.
It's not a performance issue.
|
|
|
|
|
I like .AddWithValue just to save keystrokes, but never noticed any performance difference either way.
|
|
|
|
|
I'm trying to retrieve an application from my database. I have a Data Context in my app called AppSecurityDataDataContext. Here's my query:
{
AppSecurityDataDataContext dc = new AppSecurityDataDataContext();
var app = from a in dc._Applications
where a.ApplicationId = ApplicationID
select a;
}
I'm getting "Could not find an implementation of the query pattern for source type 'System.Data.Linq.Table<AppSecurity._Application>'. 'Select' not found. Are you missing a reference to 'System.Core.dll' or a using directive for 'System.Linq'?"
I have the using statement in my class. This other method works:
public static void AddApplication(Application Application)
{
_Application app = new _Application
{
ApplicationName = Application.ApplicationName
};
_DataContext._Applications.InsertOnSubmit(app);
try
{
_DataContext.SubmitChanges();
}
catch (Exception e)
{
}
}
Anyone see what's wrong here?
Everything makes sense in someone's mind
|
|
|
|
|
Do you have the LINQ dll referenced in your project as well as the proper build target set?
|
|
|
|
|
As I said in my post, I have the using statement in my class.
Everything makes sense in someone's mind
|
|
|
|
|
Because a using statement and required dll's or correct version of dll's are synonymous.
|
|
|
|
|
The problem was that I was using System.Data.Linq, not System.Linq.
Everything makes sense in someone's mind
|
|
|
|
|
OK, so I know StringBuilder offers all sorts of nice features but if I'm only interested in iterating through a number of items and adding them to a string, is there a good reason why successive myStringBuilder.Append(myItem.ToString()) with an eventual myStringBuilder.ToString() would be beneficial as opposed to a simple successive myString += myItem.ToString()?
|
|
|
|
|
It's said to be faster. Appending to a string in a loop would preferably be done by a StringBuilder, while a normal concatenation might be more readable when using the += option.
I are Troll 
|
|
|
|
|
The real difference is in allocations... a += b is really shorthand for a = a + b, which works by creating a new string of the proper length, copying a and b to it, and assigning that value to a.
If you do that a thousand times, you're allocating a thousand strings in memory, each one a bit longer than the previous.
The StringBuilder, if I remember correctly, basically works like a variable-length array. If it starts with a length of 100, then you can just keep appending text in-place until it reaches a length of 100, at which point it'll reallocate itself to a length of, say, 200. Instead of doing a thousand allocations, you might only be doing a hundred or less. If you already know something about how many strings you'll be adding, or their average length, you can tweak the StringBuilder in its constructor to reduce this further.
It's a minor improvement if you're only adding a few things, but it really makes a huge difference in a long loop, or one that you repeat often.
|
|
|
|
|
Efficiency! But it depends on the number of your items.
If you have a small number of items use normal string concatenation (+=).
If you have a large number of items and many concatenations (i.e. in loop) than StringBuilder should be the choice.
Read more here[^]. 
|
|
|
|
|
it typically is (a lot) faster. When you have:
string[] lines=...;
string s="";
foreach(string line in lines) s+=line;
each iteration of the for loop will create a new string object and copy all data so far into it.
OTOH
string[] lines=...;
StringBuilder sb=new StringBuilder();
foreach(string line in lines) sb.Append(line);
string s=sb.ToString();
will use only two objects (sb and s), and sb.Append will copy the new data, not all the data, provided the internal buffer has sufficient capacity. The StringBuilder's capacity by default starts out at 16 characters, and doubles when necessary.
You can avoid all unnecessary capacity enlargements and data copies by providing an appropriate initiaal caapacity, so the best approach could be:
string[] lines=...;
StringBuilder sb=new StringBuilder(1000);
foreach(string line in lines) sb.Append(line);
string s=sb.ToString();
which starts out at an SB with room for 1000 characters (which would grow if required, just as before).
FYI: it does not make sense to use StringBuilder for concatenating string literals, as the compiler does that for you automaticaally. So
string s="aaaa"+"bbbbbbbbbbbb"+"ccccc";
only takes one object and one assignment.
ADDED
.NET has some methods that also help in improving string concatenation performance, without any hassle.
string.Join() is a good example.
/ADDED
|
|
|
|
|
To summarize what Luc is saying:
"myString += myItem.ToString()" will create a new string object every time it is used. This means that if you called this in a loop that executed 500 times, you would be creating/trashing and object 499 times!
Think of it this way: The StringBuilder optimizes the creation of large string objects.
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
First off you would never use:
myStringBuilder.Append(myItem.ToString())
Instead use
myStringBuilder.Append(myItem)
This becomes the reason becomes more obvious once you start using AppendFormat:
mStringBuilder.Append("The current date is: {0:MM/dd/yyyy} and the time is: {0:HH:mm}", DateTime.Now);
I use string builder out of habit, rarely using string concatenation. The general rule of thumb is if you have a loop use string builder or if you are building a large string use string builder.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: becomes more obvious once you start using AppendFormat:
It would be more obvious if you used AppendFormat rather than Append 
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
lmao, I don't usually build code when I type it in my posts. I would be surprised if any of my answers compiled.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: I would be surprised if any of my answers compiled.
<Onslow Voice>Oh. Nice.</Onslow Voice>
|
|
|
|
|
Is you posted malformed XML.
|
|
|
|
|
I had it without spaces first, but then decided to make it somewhat easier to read... 
|
|
|
|
|
My article, StringBuilderPlus, explains the problem with successive string concatenations and even has some nice graphics to help you understand. 
Basically, string concatenations take N^2 time where StringBuilder concatenations take N time.
|
|
|
|
|
Hey guys, I'm trying to generate a report from an xml file, when I view the report it only shows the first client on the first page and doesn't add the other entries.
E.g. I have an xml file as follows
<br />
<?xml version="1.0" encoding="utf-8" ?><br />
<api_response><br />
<code>ok</code><br />
<noofrows>3</noofrows><br />
<site_entry><br />
<id>1</id><br />
<client_name>NAME 1</client_name><br />
<available_hours>12</available_hours><br />
<used_hours>12:30</used_hours><br />
<entry_count>9</entry_count><br />
<bug_count>3</bug_count><br />
<development_count>3</development_count><br />
<new_feature_count>3</new_feature_count><br />
</site_entry><br />
<site_entry><br />
<id>2</id><br />
<client_name>NAME 2</client_name><br />
<available_hours>12</available_hours><br />
<used_hours>9</used_hours><br />
<entry_count>2</entry_count><br />
<bug_count>0</bug_count><br />
<development_count>1</development_count><br />
<new_feature_count>1</new_feature_count><br />
</site_entry><br />
<site_entry><br />
<id>4</id><br />
<client_name>NAME 3</client_name><br />
<available_hours>12</available_hours><br />
<used_hours>19</used_hours><br />
<entry_count>12</entry_count><br />
<bug_count>1</bug_count><br />
<development_count>6</development_count><br />
<new_feature_count>5</new_feature_count><br />
</site_entry><br />
</api_response><br />
The report shows the name and hours used and a lot of other stuff but it should show each entry (name 1, name 2 and name 3) on a different page instead it just shows name 1 and thats it.
|
|
|
|
|
Sounds like you've got a bug in your report, then. I'd fix it, if I were you. 
|
|
|
|
|
string varTempStr = "20100720";
System.Globalization.CultureInfo enUk = new System.Globalization.CultureInfo("en-GB");
DateTime billingDate1 = System.DateTime.ParseExact(varTempStr, "yyyyMMdd", enUk);
System.Globalization.CultureInfo enUS = new System.Globalization.CultureInfo("en-US");
DateTime billingDate2 = System.DateTime.ParseExact(varTempStr, "yyyyMMdd", enUS);
string x = billingDate1.ToString();
string y = billingDate2.ToString();
Why are 'x' and 'y' coming back as the same value ("20/07/2010 00:00:00")?
Why not x= "20/07/2010 00:00:00" and y = "07/20/2010 00:00:00"?
modified on Wednesday, August 11, 2010 10:02 AM
|
|
|
|
|
Because billingDate1 and billingDate2 are just DateTime objects that contain no information on which CultureInfo should be used to output their values.
What you are doing when assigning values to the objects (though ParseExact) is simply to specify how varTempStr should be interpreted. But once the DateTime objects have their values they have their values.
It is when you export those values to a string that you have to be specific as to how it's supposed to be done.
Try:
string x = billingDate1.ToString(enUk.DateTimeFormat);
string y = billingDate2.ToString(enUS.DateTimeFormat);
|
|
|
|
|
Because you're supplying the culture to the parser... So it's using that to change "20100720" into a date. Since you specified an exact format string ("yyyyMMdd"), that culture really doesn't mean much in this case, since both cultures use the same calendar.
Then, when you turn the dates back into a string (x and y), you're just using ToString(), so it's using your default culture.
You need to specify a culture-specific format provider in the ToString() calls.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
