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?
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:
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.
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.
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.
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 SiteContainer 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.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
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.
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.
I develop a windows application using c# that use sql server databases, i want to create a setup for this application to install application and install sql server as prerequisites, but i want to set a specific configuration for this sql server such as instancename, sa password and mix mode.
Installing SQL Server is not trivial and you would need to deal with licensing issues as well. There are other issues as well such as whether SQL Server is already installed and whether the user has SQL Server but has it on another box.
The license problem by itself would concern me. But just automating the SQL Server install is going to require a lot of work.
But I would suppose that to do automation that you would need to look into custom actions in the installer.
I agree with jschell and Paul Conrad, but it is easy to but sql express as a prerequisites in c# deployment problem, but i want it to installed with my configuration not the default settings,
is it possible to do that?.
It could be necessary to install a new version of Windows Installer before that.
After installation of SQL server, the database can be restored/attached by a call to osql with many parameters.
I don't know all the details, but with this information you can start and try.
I believe that it is always a serious mistake to show a Form inside another Form ! Only in the long outmoded, so called, "MDI interface" mode did you have Child Forms within a 'master' Parent Form: that is no longer considered a useful interface model.
I second OriginalGriff's suggestion to either use a Panel, or a UserControl, to display whatever inside a Form.
The really good thing about building UserControls, is their potential for re-use in other projects, or use of multiple instances of them in one project.
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
staticexternint SetParent( int hWndChild, int hWndNewParent);
int hWnd, // handle to window
int hWndInsertAfter, // placement-order handle
int X, // horizontal position
int Y, // vertical position
int cx, // width
int cy, // height
uint uFlags // window-positioning options
In a linq to sql data context object that points to a sql server 2008 r2 database in a C# 2010 application, I want to change the size of a column from varchar(500) to varchar(900). To acoomplish this task, can you tell me what I need to do so the data context object picks up the expanded size?
Create another field with the HASH of that varchar(500), and put a UNIQUE CONSTRAINT on the hash field: HASH BYTES('md5', My Long VarcharField)
This will cause poor performance but if you have a varchar(500) where you need to enforce uniqueness I'm assuming performance isn't on the forefront of your considerations anyways.
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
actually what I need it's so simple (but not for beginner just like me) I read two articles about registry manipulating but I couldn't do what I need, it's to add these values and data using C#:
to the existing key:
I tried this code but I got some errors like:
The name 'google' does not exist in the current context
The name 'goolgeEarth' does not exist in the current context
Anyway I also tried this code but nothing happened:
looks like a little miss typing in the code sample i have now corrected it, the values are going into the registry fine for me here, remember if you are looking at regedit you will need to refresh the screen View > Refresh to see the new values.
staticvoid Main(string args)
RegistryKey software = Registry.CurrentUser.CreateSubKey("Software");
RegistryKey google = software.CreateSubKey("Google");
RegistryKey googleEarth = google.CreateSubKey("Google Earth Plus");