|
MicealG wrote: it's because of people like you that people like me can't find their answers.
That has FAR more to do with your own abilities than it does our own motiviations for not answering.
MicealG wrote: Give the guy a break it's not like he wants to break the firewall to look up porn!
What did he say that lead you to believe that? You have absolutely no idea what he's going to do when/if he gets around the firewall.
Besides, unless the IP address of the machine he's using is routable on the open 'Net, it's impossible for him to "get around" the firewall.
|
|
|
|
|
I'm sorry but a Firewall is there for a reason. If you are having problems then you need to speak to the infrastructure administrators to see about them opening ports for you.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
You could try the loop back address which is http://127.0.0.1/, this will allow you to connect to the router setup page but there will be more than likely username and password security on it, the default for most hardware is username:admin and password:password, but if the networks administrator has any common sense it will be changed. None the less, it's worth a try.
Freedom is the right to say that 2+2=5 if this is so everything else will follow.
|
|
|
|
|
Congratulations, if this works, you've helped this guy hack into his school. Do you really think that's wise ?
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Yawn
Freedom is the right to say that 2+2=5 if this is so everything else will follow.
|
|
|
|
|
MicealG wrote: You could try the loop back address which is http://127.0.0.1/, this will allow you to connect to the router setup page
Really? Do you really think that "the firewall" is installed on every workstation at the school?
Do you really think that the "router setup page" would be that accessible??
You're thinking in terms of home networking, not in corporate infrastructures.
MicealG wrote: None the less, it's worth a try.
And in some cases, even an attempt at this is enough to get you booted out of school/a job.
|
|
|
|
|
I certainly know who I'm getting networking lessons from in the future!
|
|
|
|
|
I wasn't 100% sure that this was the right board to post this question in but my application is going to be in C# so thought this was the best fit. I am creating a simple lightweight app that I intend to use to keep track of the bugs I find in my bigger projects. I am a newish developer and I want to learn a bit of C# and thought this would be a useful (to me at anyrate) app to have and a good learning tool.
Now I was intending just to attach an access database to the program to store each bug record. As its just for personal use and its only supposed to be a a small utility I thought this would be safe and easiest to do without having to bother with downloading and installing a mysql database and all the rest of that kind of hassle, plus I can just take a copy of the database onto which ever machine I go to and the computer with the database server running on doesn't need to be always on. I don't do much database programming and so can't see that it is worth the effort on my part. However a friend of mine has poo-pooed the idea and is on at me now about how stupid an idea it is to use access as its 'not a real database' and I should be using mysql or at the very least sqlexpress. I am fairly ok at SQL having used it for a number of jobs and would have no probs using it as part of the application if I thought it was neccassary, but I just don't think it is...what does anyone else think? Should I just bite the bullet and download mysql or is using access 'babyish' and 'not worthy of a developer' as my friend puts it? was actually a little offended by his attitude tbh and wish I hadn't told him what I was doing but c'est la vie!
Cheers
Cads
|
|
|
|
|
SQL Server Express is a better choice than MySQL, IMO, because C# has classes to take advantage of it's features.
Having said that, I'd agree that Access is a good choice for a single user application, for exactly the reasons you stated. I'd never use it, simply because any machine I use has SS2005 installed on it. But, if I was in your shoes, I'd consider it the 'right tool for the job', as you've said. Your friend sounds like an elitist snob. Access is still alive because it does indeed fit in some situations.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I think you need to ditch your friend for being unhelpful. As Christian has pointed out, Access is perfectly fine for tasks like this - more importantly, you can upgrade to SQL Server from it as and when you decide you need to.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Thats what I thought, when I was planning it out. He got all snippy about the idea tho 
Its for me alone anyway so I guess I shouldn't really care whether he approves or not anyway!
Cheers Guys
Cads
|
|
|
|
|
For all the reason Cristian said - you go ahead and make whatever decision you feel happy with - this is after all just a learning excercise for you!
However, consider this; Say you start using your bugtracking app as single user with an access database installed right there with the application itself, and somebody else wants to be able to add/edit/view bugs. Now do you:
a) Install him as another single-user with its own database. Beraing in mind you now have 2 databases filled with bugs. (Add another imaginary 100 users... it starts getting very fragmented)
b) Rewrite the app to use a centralised database and install both users (plus the 100 more) on the new app.
Anyway, im just pointing out some things to think about. As a learning exercise you might want to look into "Data Abstraction" which basically means that you build your app to be database agnostic and when the time comes to upscale from Access to SQLServer or SQLExpress or Oracle or whatever its as simple as a reconfiguration (rather than a recode).
|
|
|
|
|
Thats really not a bad idea that. Hmmm I didn't really consider doing something like that but it may prove useful to know how to do it in the future. It might not as well, but it wouldn't hurt to know would it?  Will have a browse around t'net and try and get me some knowledge then, any articles you would reccomend I read?
I like the phrase "database agnostic" dunno why just had me chortling
|
|
|
|
|
Basically, any application that accesses a database, should seperate that database access to a seperate dll. you replace your data layer by changing the data source that dll uses, while maintaining the same public interface, so the new dll just plugs back into the old code base. In practice, I've always done this, and never had to rewrite an app to use a different data source, but it has other advantages, not least, is that if you don't use stored procs, your SQL is centralised in your code at least, making it less likely that you'll write more than one piece of code to perform the same SQL. It also lends itself to having a single connecton string that is reused by all your data base code.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Hi Cads,
Don't let anyone tell you what to do or use in all aspects of life, and programming in particular.Just do or use what works for you. You can't telkl from the frontend what you're using. Hell, I wrote programs that use an excelsheet to store my data. Saves a lot of hassle. Just use access. It's a very good database ( well, it is classed as a database ) for storing simple values. I would only recommend a more professional database if you're planning on storing Megs and Megs of data and use complicated stored procedures. This isn't the case in your application so go for access. Another pro of using access is that it's just one file, where SQL or any other DB for that matter has to be installed, instances created, etc.etc. Lots of headaches and not user friendly. Stick with access.
|
|
|
|
|
Hi,
Can anyone tell me which one is faster Hashtable or Dictionary.
Regards,
nas
|
|
|
|
|
|
If you want to know which is quicker, why not write some tests. This is the best way for you to find out because you won't end up relying on what somebody else tells you, which could be wrong.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Maybe 50 lines (or less!) would provide you with insertion/retrieval times for both.
Just for fun, I used the System.Diagnostics.Stopwatch class to get the elapsed time on adding 10,000,000 ints to both a HashTable and a Dictionary<int,int> and found that the Dictionary was faster both for insertion and retrieval.
I just for-looped for the desired number of iterations and added the counter each time to the container. On the retrieval, I just did a [key] lookup and an assigment, something like:
myint = container[key];
On the hashtable part, I did a Convert.To.Int32() call. On the Dictionary, it *knew* it was an Int already, so I just did the assignment. So, that Convert call took some time. I went back and took out the Convert call to see what impact that was having - not much, actually. Maybe 100-150 milliseconds on average for the entire run.
Interestingly (at least to me), the Hashtable was slower on retrieval when I specified the initial capacity at construction than when I didn't. For 10,000,000 items, it took about 700 milliseconds or so longer for the entire run.
Of course, your mileage may vary and my test program was not an exhaustive one.
That was as fun diversion - back to work I go!
Have fun,
Matt
It isn't enough to do well in life.
One must do good when and where one can.
Otherwise, what's the point?
|
|
|
|
|
Matthew Cuba wrote: Interestingly (at least to me), the Hashtable was slower on retrieval when I specified the initial capacity at construction than when I didn't. For 10,000,000 items, it took about 700 milliseconds or so longer for the entire run.
This is probably something to do with the fact that Hashtables have to box/unbox their data (both key AND value), whereas a Dictionary is strongly-typed.
|
|
|
|
|
Jason Hanford-Smith wrote: This is probably something to do with the fact that Hashtables have to box/unbox their data (both key AND value), whereas a Dictionary is strongly-typed.
Not sure I follow you on this. It was my understanding that retrieval of an element from a Hashtable is O(1). In both instances (whether I set the initial capacity or not), I've added 10,000,000 items to the Hashtable. I expected it to take longer to hashtable.add to the one where I didn't specify an initial capacity, as the Add is O(n) if Count>Capacity (it is O(1) otherwise), but on retrieval... well, I'd expect similar box/unbox activity to be done on the Hashtable in both instances.
It isn't enough to do well in life.
One must do good when and where one can.
Otherwise, what's the point?
|
|
|
|
|
If you take a look at the definition for Add and Item in Hashtable you'll see:
<br />
public virtual Object this[Object key] <-- Item for you VB'ers<br />
public virtual void Add(Object key, Object value)<br />
Both getting from and adding to the Hashtable involves boxing or unboxing.
On the other hand, with Dictionary you have:
<br />
public TValue this[TKey key] <-- Item for you VB'ers<br />
public void Add(TKey key, TValue value)<br />
As you can see, this uses Generics and so does not involve a type conversion or boxing/unboxing penalty.
|
|
|
|
|
Yes, I believe I understand the idea that the Dictionary knows the type already and thus doesn't have the boxing/unboxing overhead.
But, my original question was "Why would the cumulative time to retrieve N items from a Hashtable that had been declared:
Hashtable ht = new Hashtable(N);
be longer than for one declared as follows:
Hashtable ht = new Hashtable();?"
That is what I was wondering. It would seem to me that since they are both Hashtables and both have N number of items in them, added in the same manner, the retrieval time would be very similar, but it wasn't. It actually took longer for the one where I specified the capacity upfront.
Incidentally, the time to retrieve for the Dictionary was essentially the same whether or not I specified an initial capacity or not.
It isn't enough to do well in life.
One must do good when and where one can.
Otherwise, what's the point?
|
|
|
|
|
Apologies, my mistake.
Looking at it further (using Reflector), the Hashtable does some interesting things with the load factor provided that will force an automatic resize if the number of "buckets" used comes close the the number of slots available.
To test this, how about having two Hashtables using to two different initial sizes and timing the add/retrieve speed of each up to the smaller count. The speeds should be the same.
I think you'll only see the degredation when you go beyond it... it'll keep expanding to the next nearest prime above two times the current count. Which sounds like a big jump, but you'd probably hit it again pretty quick on a 10,000,000 loop.
Hope some (any) of that made sense.
|
|
|
|
|
No problem whatsoever.
You made perfect sense. I'm going to play around with the suggestions you've made here and I appreciate the responses and info. It is all quite interesting.
Take care,
Matt
It isn't enough to do well in life.
One must do good when and where one can.
Otherwise, what's the point?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
