|
I don't know if this is in the right place or not, but I'm going to assume it is and I apologise if it isn't! :P
I've been developing in C# for a year now and it's my first major language and I'm now looking to join a small project to help build my skills, or to even start one up if you have an idea! 
My strongest points are Analysis, Implementation and stuff in that general area. I also work considerably well in a team. Although, my weakness would have to be design, as I haven't really gotten very far with it. But I do have basic/possibly intermediate skills in HTML and CSS. My problem is designing in environments like this.
I know things such as basic I/O functions, operation of WMP/iTunes through DLL referencing, xml parsing, class builds, open source libraries, creating automatic update functions (the one in VS is rather crumby, if you ask me!) threading and much more.
So if you're looking for people to help out in your project, even just little, and you're interested in letting me join reply here or send me a message. And if you've read all of this then I both thank and salute you! 
modified 4-Aug-12 21:46pm.
|
|
|
|
|
You might want to at least edit your posting and remove your email address. Unless you like the spammers scraping your email and then sending you lots of nice emails for problems you didn't know you had.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
Aha yeah you're probably right! I get so much spam mail its unreal. This is probably why I get it all. Thanks for pointing that out.
|
|
|
|
|
You're welcome. And you message probably rightfully belongs in the collaboration forum.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
Yeah. I'm new to the website and don't really know much about the forum contents or navigation. My bad. 
|
|
|
|
|
Not a problem. Happens all the time.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Please stand in front of my pistol, smile and wait for the flash - JSOP 2012
|
|
|
|
|
I find getting the idea for a project to learn/play on to be the most difficult thing, therefore the few I have I hoard 
You could always peruse the codeplex stuff and see if you can join there. I have never used it but I believe it is open source and it seems reasonable that other devs would be welcome on some of the projects, especially if they are not too specialised.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I think this is a problem all developers suffer with, especially ones that are just starting out and learning the ropes. I know its certainly the hardest part for me, which is why I asked this question.
Thanks for that suggest, I just looked on there and there was quite a few interesting projects that I'm applying for. I'd recommend looking there yourself as there are some really promising applications being made.
|
|
|
|
|
|
In a C# 2010 application that uses linq to sql datacontext object that connects to a sql server 2008 r2 database, I need to do a maintenance change to modify the size of a notes field from varchar(500) to varchar(900).
I am getting the error message, "changing the data type of column 'field2' on table 'test1' from 'varchar(500)' to 'varchar (900)' causes the following indexes to exceed the maximum index size of 900 bytes: index2 when change the column size using sql server management studio 2008 r2.
I am assuming that the datacontext object added this notes field to the index? If I am correct or not, can you tell me why a data field of this size would be used as a foreign key by the data context object.
I am trying to determine what my options are to fix this problem. The following is what I noted so far:
1. I saw the table I am referring to is a clustered index and I do not want to change the index for this reason. Note there are several foreign keys in the table I am referring to, however the primary key to this table is an 'int'. The only option I can see is to increase the size of the field to varchar(886) instead of varchar(900).
2. Could I change the field to a text size? This way the field can be the size the user may need. Can you tell me if this is a good option or not any why?
3. Is there a way I could change the data context object so this field is not a foreign key to another table? If so, how would I accomplish this goal?
4. Are there any other options I would have?
|
|
|
|
|
following up on a thread in 'weird and wonderful', should i be calling .dispose at the end of a method on all objects that have it? i just checked the objects in a function here to see which ones have a dispose method (with intellisense) and they are:
//connection.Dispose(); // OleDbConnection
//selectCMD.Dispose(); // OleDbCommand
//adapter.Dispose(); // OleDbDataAdapter
//sources.Dispose(); // DataSet
should i be calling these every time (here and in other functions)?
(ignore the possibility of refactoring for now, unless necessary.)
|
|
|
|
|
Only if you instantiated it and aren't returning it to the caller.
Personally, I prefer to keep my Connections and Commands for the life of the app, so I wrap my Connections and Commands in another class and dispose them in my class' Dispose.
And I don't use DataAdapters and DataSets.
|
|
|
|
|
Countered!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
may be worth looking into the using keyword, for example.
using (var connection = new OleDbConnection())
{
}
MSDN info on the using statement here.
Code project artice also here
|
|
|
|
|
As PIEBALDconsult said: if you create it, you should dispose it when you are finished with it.
The problem is that some objects use scarce resources, and unless they are disposed those resources do not become available for other classes within your app, or other applications until the Garbage Collector identifies them as unused, or the app ends. Since this may not happen for minutes, days, or even months, it is a very good idea to get into the habit of Disposing everything which implements IDispose. This is particularly true of SQL components, Graphics releted items, and files.
You may not notice a problem, but it is potentially there to bite you in production, and extremely difficult to track down and fix - since all you get is normally "out of memory" errors, with no indication of what caused it.
The easiest and cleanest way if to wrap the object in a using block as this also takes the object out of scope when it is Disposed, so that it cannot be accidentally referenced later.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
You should dispose of instances which you are 'in charge of' (i.e. you created and have not handed out persistent references of to other classes), when you are done with them.
Because of how database interaction is limited (concurrent connections usually being the limiting factor), you usually want to create, use and dispose of connections, commands and transactions quickly. For this you should use a using statement.
|
|
|
|
|
BobJanova wrote: you usually want to create, use and dispose of connections, ... quickly
Buuut... Connections use connection pooling; they don't actually use a connection until you open it, then it's returned to the pool when you close it. So you can hold onto a Connection for a long time and only open it when you need it.
|
|
|
|
|
So you should use Open and Close instead of new and Dispose on them?
|
|
|
|
|
No, use all four.
new, open, close, open, close, ..., dispose.
|
|
|
|
|
i see what ur saying. there's a clear diff b/t the (conn) object and what you do with it (opening/closing). don't destroy it if ur going to keep using it, etc. (for conn obj).
tnx for the 'using' tips et al.
thanks all
|
|
|
|
|
For a moment, let's assume that we are talking about a SqlConnection here. When you call Dispose on the connection, all it does is call Close and then calls Dispose on the object it derives from (which just fires off the EventDisposed event to any listeners, and removes the instance from any Site Container instance. So, what does all this have to do with the price of fromage?
Well, the only part that is of any real interest there is the Close, so given that this is all that the Dispose is really doing, you are fine keeping the connection available for use, and just use Close on it until you really are ready to get rid of it.
|
|
|
|
|
PIEBALDconsult wrote: So you can hold onto a Connection for a long time and only open it when you need it.
True but in normal practice that shouldn't happen.
First the significance in the object is the connection. If there is no connection then the object itself is light weight so creation itself isn't doing anything (again for most situations.)
Second if you keep it around you must explicitly manage the state. So to reuse it you would need to either explicitly check the state or implicitly assume the state is correct. The first case requires additional code and the second leads to complexity as the maintenance engineer would need to insure correct state. Both of those cases are more easily solved by using creation.
|
|
|
|
|
jschell wrote: If there is no connection then the object itself is light weight
I wouldn't assume that; this is .net.
jschell wrote: you must explicitly manage the state
I have no problem with that. I've written Windows Services that hold a single Connection for months and never had any trouble using Open and Close as needed, perhaps millions of times.
|
|
|
|
|
PIEBALDconsult wrote: I have no problem with that. I've written Windows Services that hold a single Connection for months and never had any trouble using Open and Close as needed, perhaps millions of times.
I didn't say it couldn't be done. And usage of course would have nothing to do with whether it was correctly implemented in all cases except of course that if there is an incorrect usage then it is more likely to show up with high volume.
|
|
|
|
|
jschell wrote: more likely to show up with high volume.
Indeed.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
