Afraits

Use the Fileinfo class to get information about the file before opening it, or use the basestream property of the streamreader which should then provide access to the base Filestream property of length, the filestream class also exposes a property position which should give the byte position within the file. Alternatively you can count the number of bytes in each line of data that you read and track the position that way.

You should be able to get the total file length and the number of bytes read in each line - hence display the bar as the proportion of bytes read rather proportion of lines read.

DBConcurrency exception will usually mean that a row has changed in the underlying DB between you populating the grid and trying to update it. Is that scenario possible?

If you are performing string parsing - perhaps regular expressions may be useful for you, although more overhead they are quite flexible and powerful and so may work out better in the long run, check the regular expressions for examples and as a place to post questions. For your actual question however I have no idea :)

Investigate the System tables within SQL Server, they do take a bit of understanding to know what is going on though. The starting point would be sys_objects.

Yes the datagrid should populate changes back to the dataset if its a bound control and you haven't set the grid to read only. Then its just a matter of calling dataadapter.update to move changes back to the DB. But if you are in a multiuser environment do some research on concurrancy first to avoid problems when multiple users change the same thing.

Besides checking the width of character 'M' and comparing it to 'i' (for example) which will only be the same for a fixed width font? going off memory some font formats do have flags that say whether a font is fixed-width but that would require you to understand the font format and parse the font file itself i think.

According to ducumentation on MouseWheel event arguments, one mouse wheel click gives a delta of 120 (+ or -), 'aggressive scrolling' may then register more than 1 click between events being raised.

That error would suggest that the format of the date in the string format you pass in isn't valid or isn't being interpreted correctly, so first step ensure a valid date is being passed in, secondly try an explicit format such as 13-MAR-2005 instead of 13/3/05, thirdly use the 'CONVERT' command in SQL Server to specifiy a format eg CONVERT(DATETIME, '''+ @DOB +''', 103) would expect an English style datetime format. Having looked at the sp I think the part " ... , '+cast(@DOB as datetime)+' , ..." should be written "..., CAST('''+@DOB+''' as datetime) , ...." (or the convert if you go that way) Hopefully one of those will solve the problem.

Perhaps you could post as much of the stored procedure as possible so we can see how you've set it up.

A primary key is the main index on a table, and as such will speed up queries and navigation especially when tables are linked via such fields. It is good practice to always have a primary key on a table.

Yes, you will need to raise events do pass property changes back to the form. You may notice that in the textbox's event list it contains events such as backcolor_changed which are providing the text box with the functionality you wish to implement for your person class.

If its part of the framework isn't it referenced automatically? And as .NET 2003 points at the 1.1 framework by default and this is a V2 framework feature then there is likely to be be a compatability issue.

You can call a DTS package from code as I've maintained code that does it, unfortunately I don't have access to that code anymore. :o But it can be done.

True, a lot does depend on what you are trying to do and why you want to do it a particular way. In my first post I almost added in a proviso that using regex may be overkill but then decided not to :p If you need to do a case insensitive replace on a string while leaving the rest of the text unchanged then regular expressions are the only way I know. However why this is necessary I'm not sure. So your point is valid and perhaps JDYoder could tell us exactly why changing the case of the rest of the string is a no go. I would also add that using the stringvar.ToLower().IndexOf (or ToUpper) would be fine if all you are after is a position within the string.