In .NET regex language there is a character class "\W" that represents "non-word characters" (i.e. characters other than letters, digits, or underscores). You could also replace your [0-9] with "\d" (note the lower case). P.S. I think this question may be better suited for the regular expressions forum.

Are you certain that you need a generic for this scenario? It sounds like a simpler List<employee> would do just fine, no?

Short answer is "yes, it is possible". The long answer is a lot less pleasant: it can't be done for free. Pulling this trick requires work. In fact, it requires a lot of work. Here are the basic steps: 1. First, you need an expression library capable of evaluating expressions presented to it as strings. You can either build one (making a high-performance evaluation library on top of Linq expressions is surprisingly simple), or adopt one written by someone else (for example, this one: Expression Evaluator[^]). 2. Next, you will need to build a Converter class, which is a small adapter for using your expression evaluator in XAML. One class can implement both IMultiValueConverter.aspx[^] and IValueConverter[^], and expose a string property called "Source". 3. Import the assembly with your adapter into your XAML file by adding a clr-namespace referencing your assembly to the Windows element. xmlns:Converter="clr-namespace:MyNamespace.Converter;assembly=MyConverterAssembly" 4. Add a resource for each expression that you would like evaluated from your XAML:

<Converter:ExpressionValueConverter
x:Key="CalcTotalWeight"
Source="(arg1 * 126) + (arg2 * 220)"
/>

5. Use binding or multi-binding to attach your expression to labels and text boxes in your XAML:

<MultiBinding Converter="{StaticResource CalcTotalWeigh}" FallbackValue="0">
<Binding Path="txtA"/>
<Binding Path="txtB"/>
</MultiBinding>

I went through this exercise once, and I can tell you that it is not easy. And I started with a well-tested expression library from step 1! But once you put it all together, it looks like a small miracle.

I'm curious what are you trying to achieve with a method like this. Since you are forced to specify an exact type at the point of call anyway, for example,

var managers = getall();

you might as well call a method with a different name, like this:

var managers = getAllManagers();

In other words, your getall method hides certain details, yet the caller is forced to reveal these details back! Could you please explain your intent?

You can try the other overload[^] of the DbDataReader's Item[] property:

using (DbDataReader dr = command.ExecuteReader())
{
while (dr.Read())
{
String col1 = dr[1];
}
}

Notice as well that the text itself is a element value. A text that does not represent a value of an enumeration should always be in an element, because of the mandatory attribute normalization in XML. So exactly how would you structure the data of the OP such that an element value has attributes which are properties? Like this:

Personally, I would prefer the markup below as more consistent, but the one above is perfectly OK.

<meter ref="00895289">
<reading date="14/12/10" value="2"/>
<reading date="28/09/10" value="0"/>
<reading date="23/08/10" value="0"/>
<reading date="02/03/10" value="9"/>
</meter>
<meter ref="00895298">
<reading date="02/12/10" value="275"/>
<reading date="22/09/10" value="274"/>
<reading date="02/06/10" value="274"/>
<reading date="02/03/10" value="274"/>
</meter>

in my experience attributes also suffer from a lack of easy display and no way to comment values (xml comments.)

I tend to disregard display concerns, as XML is not specifically a presentation-oriented language. As far as inability to comment attributes goes, I think that humans should not be exposed to reading and writing XML so much as to need comments. There was an excellent post on the subject[^] ten years ago, which I think is even more applicable today.

Why? The most complete treatment of the attribute-vs-element question[^] that I was able to find mentions the principle of structured information, saying that "If the information is expressed as an atomic token, use attributes." I've been intuitively following that rule for many years, because it is easy to remember, it results in consistent schemas, lends itself nicely to use in automated schema generators, and makes resulting documents more compact. That's why I think that using attributes in this case is desirable.

As others have noted, the problem can be re-stated in terms of a system of linear equations. A particularly easy method to solve such systems (in relative terms, of course - it's a decent homework assignment for a second-year CS student) is the method of Gaussian Elimination[^]. Here is a Java implementation of what you are trying to build[^], conveniently packaged with a source code. The implementation is very easy to follow, even if you do not know Java (but do know some C#). Good luck!

I would definitely ask them to make reading items meters' children, rather than siblings. While they are at it, I'd ask them to put dates and values into attributes too. Depending on the technology that they use, it could be as simple as ten-line change on their end. Doing the work on your end invites maintenance headache, with a potential of costing your company a lot more. Especially if someone inherits this project from you, and needs to implement enhancements.

Although the example you gave does not exploit XML to its fullest potential, it's a welcome departure from entirely unmarked text files with pipes used as separators. I've seen XML that encodes list indexes in tag names, like this: <item3>78</item3> <item1>34</item1> <item0>12</item0> <item2>56</item2> So I don't think your situation is quite as bad :-D I think that your answer greatly depends on what you are planning to do with this data, and how hard it would be for the provider to change their code to generate a more XML-like XML for you. If your provider is a utility company in the United States, you will almost certainly be better off just working with the flawed format. Otherwise, you risk spending countless hours convincing them to change the format for you, and then ending up working with that flawed format anyway :-(

You need to check the Item for equality to VT_NULL before calling it's GetValue() method, like this[^].

Although Entity Framework has replaced Linq2Sql in Microsoft's technology stack, the philosophy behind the APIs remains the same. Whatever you've learned about Linq2Sql will help you in EF. My observation is that ORMs are a lot more flexible on the data query side than on the data manipulation side. I tried Hibernate/nHibernate, Linq2Sql and EF, and in all cases the data retrieval was impeccable. Writing data back, however, was a different story: all frameworks are great when you modify your data in memory and then write it back, but you must jump through the hoops to implement mass inserts (e.g. table-to-table copies), updates, or deletes. Here is a good link that explains the issue and provides a work-around for Linq2Sql[^]. Good luck!

Others have answered the 'why' question, so let's go straight to the 'how' part. As clever as it may seem, your trick does not work, because SQL server does not let you parameterize dynamic SQL. However, you can trick it by observing that dynamic SQL is essentially an anonymous stored procedure; once you give it a name, you can start passing parameters to it.

Given the abundance of useful free stuff on the net and the availability of commercial libraries sold directly or through companies that have been selling software components for nearly three decades (e.g. programmer's paradise), I doubt that your business model stands a chance. On top of that, people who want money for their software would be reluctant to sell their source code, out of fear of it acquiring a life of its own (for example, in the shape of a competing closed-source product).

1. Instead of going through strings to construct an instance of DateTime, you should use the corresponding constructor: new DateTime(yr, mn, dt) 2. Instead of building a SQL string with embedded values, use parameterized SQL[^]: it makes your code more robust, not to mention considerable performance gains.

I think that you've been thrown off by the meaning of the word "heap". Although it usually means what you think (i.e. an in-memory data structure[^]), in the context of the discussions that you quoted it means a heap-based table[^]. Anyway, Key Lookup is logically identical to RID Lookup. Physically, there are significant differences, but nine times out of ten you can count them with the rest of unimportant implementation details.

You are welcome!

For a method returning a single string, this is rather wasteful: you bring in a list of items in memory (with a call of ToList()), then run a join, but then you throw away all but the first item of the result! You don't need a list of teQUTUData objects in memory: all you use is their DeltaReportBinaryDataID column, so select only that column in your first LINQ query (add .Select(a => a.DeltaReportBinaryDataID) to the first query). Next, you don't need a join in your second query: it's an in-list lookup. Rewrite your query to run a select from parallelDataContext.teBinaryDatas, where quarterlyUpdateSubscription contains b.BinaryDataID. This should do the trick. Good luck!

Could you give more details on the exception that you are getting? Is it coming from POCO or from the DB? The code appears lifted straight from the POCO example book - the only difference is that you use an int, while they use a string. Assuming that their example works, and that you also use SQLite, there's only a small number of places where you could get an error. First thing I would try is specifying the list of column names: INSERT INTO TableName (myIntColumn) VALUES(:size): the single-column syntax looks suspicious. Then I'd look at the error coming back, and try to decipher it.

1. No problem 2. This does not make any more sense than "for loops are not high performance statements". 3. Assuming TBL1 and TBL2 have identical structure, you can do it like this:

select * from TBL1 where @flag=1
union all
select * from TBL2 where @flag<>1