RSS feed for InstantSpot site EdomGroup Blog

Configuring SQL Server Express 2005 For Remote Connections

Sat, 11 Aug 2007 15:01:57 GMT

This is a reference guide to change the settings in SQL Express Server to allow remote conections. I found most of my information at http://www.datamasker.com/SSE2005_NetworkCfg.htm , and I will be trying to simplify what is said there.

Configure SQL to use TCP/IP connections as well as local connections in the Surface Area Configuration Utility.
Select the Services and Connections section.
Under Database Engine -> Remote Connections choose to use local and remote connections (TCP/IP only or TCP/IP and named pipes). You can also do this in the SQL Server Configuration Manager tool under:
SQL Server 2005 Network Configuration -> Protocols for SQL Express
Now restart/start the SQL Server service.
You now need to configure Windows Firewall (only if you have it running) to exempt SQL Server and SQL Server Browser. To do this you simply need to add sqlservr.exe and sqlbrowser.exe to the exceptions.

The files can be found at:
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe
C:\Program Files\Microsoft SQL Server\90\Shared\sqlbrowser.exe.

You should have a successfully configured SQL Server, so start trying to connect to it remotely. If you are still having issues it may be necessary to restart the computer for all changes to take place.

Craig.

Query Analyzer Auto-Complete...Woot!

Wed, 04 Apr 2007 12:51:50 GMT

This is something I've wanted for a very long time, but did not have the room in my budget to purchase a tool for.

A company called Red Gate (http://www.red-gate.com/products/SQL_Prompt/index.htm) has a nice piece of software that provides a whole bunch of features for SQL Server and looks to be very much worth its $195.00 price tag.

Apparently though, they released an older version of their tool for free that is still available here:

http://www.bustercollings.com/...

If you've been dreaming for autocomplete in Query Analyzer, then definitely check this thing out. It is a little annoying that it does have to make a seperate connection to the SQL Server to get the database metadata, but very quick and painless. And it makes it so easy to get all your tables / columns while you type.

Enjoy!

Mike.

Java performance analysis - a real life example

Fri, 02 Jun 2006 03:43:25 GMT

For my thesis I'm writing a Java program that parses two text files (representing satellite images) and performs some analysis on them. The two files are 128 MB and each was taking ~33 seconds to parse. The analysis takes only a fraction of that time, then the results are written back to an output file.

Thinking this was very slow, since the files should be pretty much sequential access off the disk and the read-ahead-buffer would have cached the next block, I decided to dig a little. I rewrote the parsing algorithm in C since it's easier to manage the low-level IO. I used the file stream functions (fopen,fread,fclose) provided by stdio. When I ran the program it took ~10 seconds.

This was insane. Java does have more overhead due to its garbage collection, HotSpot optimizer, and object memory management but it should not be a magnitude of 3x slower. After a few minutes looking at the Java implementation I realized I had forgotten to instantiate a BufferedReader. I immediately jumped to the documentation and there it was, each call to the read method of the FileReader blocks until data is available. If no BufferedReader is supplied this means a context switch for each call. No wonder Java was taking so long. Adding the buffering I reran the algorithm and wow, 13 seconds. Not to bad for a “boated” language.

Figuring I had more places in my program which could be optimized I began looking. The first place I went was to one of the main methods, the one which did the analysis on each image. The logic was pretty simple, find the next pattern in the given image, see if it exists in a lookup table, if so update its statistics or create a new key and add it as a new entry. The data structure I was using for the lookup table was a simple HashMap object. When writing that section of the program I was still relatively new to the Java language and just went with what I'd used in other languages, an associative array.

I did a little analysis with some System.out.println statements and found that on average there was a 14,000 : 15 ratio between reads and writes on the lookup table. Knowing this ratio was pretty stable (I wasn't going to get anywhere near 50% writes) I decided a better data structure would be something with read time of O(n) or less, instead of O(h(k)) where h(k) was the hash function on the key. This meant an array would be best, but I didn't want the hassle of managing the size of the array as new patterns where found. Java had to have something for this. After a little searching I found java.util.concurrent.CopyOnWriteArrayList. This was exactly what I needed. After a little tweaking the new code ran in 1/3 the time.

After this I wrote some small timed programs to examine the running time of the HashMap data structure and the CopyOnWriteArrayList. What I found was as the mutations approached 25% the CopyOnWriteArrayList's performance slowed at an exponential rate. Finally, I couldn't evaluate the performance because the tests were taking too long. On the other hand, the HashMap data structure had a fairly constant performance time irrelevant on the read/write ratio.