|
SqlParameter enteredBy = new SqlParameter("@enteredBy", SqlDbType.BigInt);
enteredBy.Direction = ParameterDirection.Input;
enteredBy.Value = Convert.ToInt64(Session["CMSID"]);
sqlcommStoredproc.Parameters.Add(enteredBy);
|
|
|
|
|
Are you sure session["CMSID"] is a 64 bit int? People have been known to put all sorts of crazy things in there (maybe an unsigned version)
Check typeof(Session["CMSID"]) and see what you get. And if it is a string go kill yourself.
|
|
|
|
|
|
Value isn't a type. Check the type. Use the typeof operator.
|
|
|
|
|
Strictly speaking, you don't need to do the conversion against Value as it's an object , so it could contain anything you like.
|
|
|
|
|
When I do a Session["CMSID"].GetType() - I get it as System.UInt32.
I tried to cast as same and it still comes back with error.
|
|
|
|
|
But, you don't need to perform any cast. You're putting it into an object, so there's no need to perform the cast in the first place.
|
|
|
|
|
Post the code where Session["CMSID"] is initialized.
|
|
|
|
|
It is requesting from querystring.
Session["CMSID"] = Request.QueryString["CMSID"];
In the database it is set up as BIGINT datatype.
|
|
|
|
|
Try this:
enteredBy.Value = Session["CMSID"];
|
|
|
|
|
Same error message - Arithmetic overflow error converting expression to data type int.
Thanks for helping!
|
|
|
|
|
enteredBy.Value = ((Int64)((UInt32)Session["CMSID"]));
Maybe?
|
|
|
|
|
Specified cast is not valid. - the message I am getting.
|
|
|
|
|
And what happens if you just use:
enteredBy = Session["CMSID"];
|
|
|
|
|
Is there a difference between string and String?
I have read on the web that there is no difference.
If there is no difference then why is one with small s and the other with capital S ?
Thanks
|
|
|
|
|
The String is actually the class System.String . It is the class that works on strings in .NET no matter what language you use. The string is the C# alias that corresponds to the System.String class. So, they're essentially the same.
|
|
|
|
|
There is no difference between them - string is an alias for System.String, in the same way that int is an alias for System.Int32. There have been various theories over the years as to why they have aliases, but I suspect the answer lies simply with the fact that things like string or int look more like their old C/C++ counterparts than String or Int32 which look very VB.
|
|
|
|
|
Pete O'Hanlon wrote: I suspect the answer lies simply with the fact that things like string or int look more like their old C/C++ counterparts than String or Int32 which look very VB.
I think it has more to do with the evolution of 'short/int/long' in C and less to due with making it look like another language. C has a tendency to keep the size of its integers in line with the common CPU register size. Some C programs are created with the assumptions that these won't change, and errors can crop up as a result of these types expanding in size. There's an article at Gamasutra about these errors (C/C++ based article, so brace for pointers and address arithmetic).
By aliasing the native type to System.Int32 (or potentially Int64 in the future), you can use 'int' for general purpose integers that fit nicely into registers where the bit size isn't relevant. Using Int16/Int32/Int64 will still give you control over the specific sizes where it might be required. A lot of C/C++ compilers have started doing something similar by creating non-standard typedefs of __int16, __int32, and __int64 to give the programmer more explicit control of their data type sizes.
Of course, as you said, this is all theory and speculation on my part.
|
|
|
|
|
As mentioned, 'String' is a class (c.f. Int32, Single). string is a C# language construct which is translated by the compiler to a suitable string class (c.f. int, float). It's extremely unlikely that it will ever translate to anything other than System.String so they are essentially equivalent. (This may not be true for some of the numeric types, int and long might not mean 32 and 64 bit forever.)
|
|
|
|
|
BobJanova wrote: int and long might not mean 32 and 64 bit forever I think this statement is incorrect. Int32 is always 32-bit irrespective of the size of the underlying platform's native integer type (that's why the name itself has the size - Int32). The same holds good for Int64.
|
|
|
|
|
Int32 is always 32, yes. But does the C# language construct 'int' always map to Int32? Let me rephrase that: is it guaranteed that that will always be the case? I thought that it was not (i.e. in some future machine configuration 'int' will mean Int64 and 'long' will mean Int128).
|
|
|
|
|
BobJanova wrote: I thought that it was not (i.e. in some future machine configuration 'int' will
mean Int64 and 'long' will mean Int128).
That is true of C, and it's a very bad idea, C# straightened that out.
|
|
|
|
|
BobJanova wrote: in some future machine configuration 'int' will mean Int64 and 'long' will mean Int128 Wouldn't that break existing apps that use int ? I am highly doubtful of such a situation. And by the time 64-bit becomes the de facto architecture, Microsoft would come up with some breathtaking new technology that would replace .NET
|
|
|
|
|
arkiboys wrote: I have read on the web that there is no difference.
..and what does the manual on MSDN state?
Bastard Programmer from Hell
|
|
|
|
|
Since Intellisense on instances of both 'String and 'string show the same underlying exposed properties and methods, and since the pop-up showing the constructor overloads for both shows the same parameter options, and since comparison of their 'Type, via GetType(), shows equality: ergo, I conclude they are the same, hence having both usages is meant for some semantic purpose.
My hypothesis for what that purpose might have been would be that code written where 'string is used to indicate the creation of instances of type 'String, and 'String is used to indicate accessing the static methods exposed by the 'String class ... might be clearer.
But that's just a guess, and it would be interesting to know what the language designers intended.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|