|
In what sense is it not solved yet? You are going to have to give us all a clue!
CCC solved so far: 2 (including a Hard One!)
37!?!! - Randall, Clerks
|
|
|
|
|
My setup should create a copy of "exe" here..
"Users\Guest\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\startup\My.exe"
so when users logon to his system then it will run automatically...
If there are anyother way to do that please let me know.
|
|
|
|
|
in the directory you pointed should be only a shortcut..
and it's done in a way keefb described
life is study!!!
|
|
|
|
|
Yes worked!!
Thanks guys...
|
|
|
|
|
Hi,
I was writing a validation function. Which is as follows
private void IsFolderValid1()
{
return false;
}
and somebody suggested me to write it in following way.
private void IsFolderValid1()
{
Get
{
return false;
}
}
Can u please explain me the reason. Whether it is right or wrong ?
Thanks
|
|
|
|
|
Your first version is right. Getters and Setters should be used for properties.
|
|
|
|
|
Hi,
none of that is correct, for several reasons:
1. if a property or method returns "false" its type should be boolean, not void.
2. property and method names normally shouldn't contain digits
3. method names normally contain a verb, and property names may or may not (preferably not, although IsValid would be acceptable)
4. private members use pascalCase, public ones CamelCase.
5. properties should always be public (protected could be OK, private is a bit strange).
6. properties don't take parentheses.
So choose one of these:
public boolean IsFolderValid() { ... return false;}
public boolean FolderValid {
get { ... return false; }
}
|
|
|
|
|
Hi there
I am building some database layer code and trying to be as database independent as possible.
One peeve is datetimes.
Does it make sense to avoid the use of the datetime objects provided by the database provider altogether and use a double field? Then use persist the dates to the double field using the DateTime.ToOADate method?
It seems to me then that I could easily do date comparisons such as "retrieve rows where date > <date>" where the <date> is converted to OA?
|
|
|
|
|
Why not just store the dates as ISO-8801 format?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
peh. store dates as strings? what's wrong with the existing date and datetime types, they have sufficient support.
IMO strings should be avoided for anything that isn't really a string, i.e. numbers, dates, ..., with a possible exception for small binary data encoded with say base64 (when BLOB isn't available or too expensive).
and then of course one should use SQLparameters to provide data, not string literals, when querying with e.g. a WHERE clause.
|
|
|
|
|
Luc Pattyn wrote: what's wrong with the existing date and datetime types,
For one, MS SQL Server only supports a subset of DateTime values, so your business layer needs to work around this before you store them in the db. Note, I'm not advocating store timestamps as strings.
/ravi
|
|
|
|
|
Except that bubba there wanted to make it db agnostic, and I've worked with a couple of databases in the past that have crap date and time support (hello Ingres, yes I'm talking about you, you malformed piece of relational dataloss crapturd).
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
we could agree on Ingres not being a database then, hence no need to dumb down the whole world and turn agnostic into stupid. Next someone will find a "database" that can't handle real numbers; or strings of more than 6 characters; or Unicode...
When he asks "Does it make sense to avoid the use of the datetime objects..." my answer is NO.
|
|
|
|
|
Or one that doesn't have operator precedence?
|
|
|
|
|
Luc Pattyn wrote: When he asks "Does it make sense to avoid the use of the datetime objects..." my answer is NO.
I'd agree with that
Luc Pattyn wrote: agree on Ingres not being a database
and that.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: I'd agree with that and that.
I'm glad to see you're back to normal; I suggest you keep ignoring the toaster. 
|
|
|
|
|
Luc Pattyn wrote: I suggest you keep ignoring the toaster.
I've kicked the hussy out. I only have eyes for the microwave now.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: I only have eyes for the microwave now
I must warn you, microwaves can harm the eyes. And Ray-Ban won't offer adequate protection.
|
|
|
|
|
Ryan Minor wrote: Does it make sense
No, it doesn't.
I use several different database systems and the only problem I've had with DateTimes is that they don't all agree on which range of dates to support. So unless you're storing historical (or far future) data, you probably won't have any trouble.
|
|
|
|
|
IMHO adding a non-exhaustive list of those DB systems would turn that into the perfect answer...
|
|
|
|
|
Ooookaaay... I'll get right on that.
|
|
|
|
|
One thing to bear in mind is whether this database will be used for anything else, e.g. accessed directly from reporting tools rather than through your application code. In this case, holding the dates as a double may cause problems for the person writing the reports.
Personally, I would consider making the data access layer pluggable, with a separate table gateway[^] for each RDBMS you are going to support. That way, if your database has good date type support you can use it, if not you can fall back on using doubles. Either way, the bulk of your code doesn't know and doesn't care. In fact, you might only need two gateways: one that supports date types and one that doesn't. Then you have a simple configuration switch to flick at deployment time to control how the application stores data.
(Actually, that link above isn't the most helpful in the world. Buy the book, it's very good.)
|
|
|
|
|
hi,
i have developed a windows service with c# and in my service a routine run at specific time to fetch data from sql server but i saw sometime i am getting error like below
A network-related or instance-specific error occurred while establishing a connection to SQL Server
can anyone tell why i am getting the above error some time. please help.
thanks in advance
tbhattacharjee
|
|
|
|
|
1. Make sure your database engine is configured to accept remote connections
• Start | All Programs | SQL Server 2005 | Configuration Tools | SQL Server Surface Area Configuration
• Click on Surface Area Configuration for Services and Connections
• Select the instance that is having a problem | Database Engine | Remote Connections
• Enable local and remote connections
• Restart instance
2. Check the SQL Server service account
• If you are not using a domain account as a service account (for example if you are using NETWORK SERVICE), you may want to switch this first before proceeding
3. If you are using a named SQL Server instance, make sure you are using that instance name in your connection strings in your ASweb P.NET application
• Usually the format needed to specify the database server is machinename\instancename
• Check your connection string as well
Did you, even for a second, consider using google? I got over 36000 hits on that error message.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
After working in Visual Studio 2008 with SP1 on my application, everything works sweet with visifire charts.
I then create an install for my application and deploy it to a seperate machine. Charts do not work, and we get system.exception with Eventype:clr20r3
Can visifire be run without VS 2008? I don't expect to install VS 2008 SP1 on every install instance of my app with visifire.
I'm using WPF, and am creating the chart dynamically through code. I'm using the latest stable/non-beta version of visifire, v2.1
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
