I hope this article, posted today on the DAW Development Team blog, clears up most questions.

To show your support for Google to test its new service here, please visit Big Gig Austin.

Visit KVUE.com for an article about this effort.

Visit Google’s Fiber for Communities project page for more information about this project.

It’s nice to live in a place with a thriving developer community and other coders who view software development as craftsmanship.

I also learned what a fishbowl is. Very cool!

The next logical question is how do I find files that are not indexed?

The Search in Windows Vista had an Advanced Search button, which would allow you to check the option “Include non-indexed, hidden, and system files (might be slow)”. I see no way to do this in Windows 7.

One way to be able to actually find a DLL file is to go to the folder it is in (in this case c:\Windows\SysWOW64) and then search for it. In other words, if you know where a file is, Windows can help you find it. Very helpful. Actually it’s worse, it will only help you find it in that folder.

It is very weird how difficult it has been to find a solution to this question. I figured out one answer myself:

dir c:\msxml6.dll /s

Has it really come to this? Do I need to revert back to what I last did in DOS to find a file while running the latest Windows operating system in 2010?

In part 1 of exploring the Windows 7 search I thought it was simply unintuitive but had potential. Unfortunately, after more research, things have turned for the worse. I can’t see myself relying on this search for anything. I will have to resort to Google desktop for file content searches and the command prompt or some other tool for file searches.

I really want to like the Windows 7 search. It certainly allows you to perform more, faster, and more thorough searches than previous Windows versions. It is also far more versatile. It’s just really unintuitive if you want to do anything other than the default. I want to try to use it as much as possible; sometimes new features turn out better than your first impression once you really use them.

Thus far, I ran into a couple of gotchas, and here are solutions to both:

• Searching full local drives

  I typed the file name into the search window for example:

  msxml6.dll

  Out of the box, this returned all documents containing that file name as text, but not the locations of that file on my PC, such as the Windows system32 folder. The problem was that the predefined libraries did not include my complete local hard drives, but only some predefined locations, such as My Documents, Music and Videos. As a programmer, I often search for the locations of specific files on my entire local drive(s), just to make sure I don’t have a stray copy in the wrong place.

  I added a new library named All Local Drives and added C: and D: (both local drives) to it. Now the search finds all copies of this file on both local drives, as well as all files that contain the file name as text.

  Caution: Your libraries are also used as default locations for the built-in Windows backup, so adding more locations as libraries for searches will also back up those locations by default. You can go in and change locations to back up in Control Panel > Backup and Restore.

  I had expected this to be automatic after adding C: and D: to my indexed locations in Control Panel > Indexed Locations.

  Caution: By default, Windows will exclude some locations such as the Windows and AppData folders from the Index and it’s quite cumbersome to even figure out what some of these locations are and include them. This really ought to be simpler!

  Update: It turns out that this issue is far worse than I thought. Please see Searching in Windows 7 part 2 for more.

• Filtering searches

  You can use a filter to constrain the search results to only display files, and not files containing the text. For example:

  msxml6.dll type:=.dll
  

  Now the search finds all copies of this file on both local drives, but not files that contain the file name as text.

• Searching multiple Exchange mailboxes

  I have a personal mailbox on our Exchange server, but I also have access to 2 additional mailboxes that I frequently need to find emails in. Windows 7 does not allow me to search these additional mailboxes.

  I had really hoped not having to install Google desktop on my Windows 7 machine (why use two searches if one will do?), but this item is a big deal to me and that was ultimately the solution.

My favorites are new features to make code navigation simpler:

• Call Hierarchy: being able to see in design mode what method calls and is called by other methods is brilliant! This is only available for C# in this revision, but that’s really the only .Net language I code in anyway.
• Navigate To: an easy way to type any part of an identifier name and find it anywhere in the current solution.

I’m really happy about this. One of the most cumbersome things when working in Visual Studio has been navigating through code.

I still miss one of the best features of Visual DataFlex Studio, Code Explorer, in Visual Studio. While I appreciate the improvements for making code easier to find in VS 2010, I always have Code Explorer open in the Visual DataFlex Studio. Code Explorer is a docking panel that displays the structure of the current code file. This makes it very easy to locate a class, object or method with a click.

Class View at first appears somewhat similar, but the way it’s implemented, it still takes a lot more steps to find something.

The database is SQL Server 2008 Express running on a Windows XP Pro SP3 PC. The database can still be accessed from the server PC itself and another Windows XP Pro PC. Attempting to connect from 2 Vista workstations, both Ultimate, but one 32 bit and the other 64 bit, now results in an error:

Connection failed:
SQLState: '01000'
SQL Server Error: 53
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Connect()).
Connection failed:
SQLState: '08001'
SQL Server Error: 17
[Microsoft][ODBC SQL Server Driver][DBNETLIB]
    SQL Server does not exist or access denied.

The same thing happens whether we use a trusted connection or the sa login (just for testing to check if the problem was a permissions issue).

I intended to post the solution to this issue here this week, but I haven’t found one yet. My hope was that if this was a result of a Windows update, I would find more information about it this first week of January as more people returned to work and others ran into the same issue.

Update:

I found the solution to this by simply debugging the problem based on the symptoms. All information I found about this error talked about opening ports to allow SQL Server access. The culprit was the Windows Firewall on the Windows XP Pro PC hosting the SQL Server database. One of my test steps was to temporarily disable the Windows firewall and this made everything work as before.

So, I enabled the firewall again and added exceptions for TCP port 1433 and UDP port 1434. This resulted in a different error (HYT00 “timeout expired”) during he initial login attempt, but worked on subsequent tries.  I was able to resolve this error by allowing outgoing time exceeded messages via ICMP in the Windows firewall settings.

None of these exceptions or allowances were ever enabled before this problem started, so something changed to cause this to happen. My money is still on some Windows or SQL Server security update. I wish I had more time to track this down further and find the culprit, but I’m happy to have a working solution now.

This is great; it allows you to develop and run a database application without requiring a connection to an SQL Server or even installing SQL Server on the client PC that runs the application. You can then use this as a standalone single user application or synchronize data between the application’s local cache and a running SQL Server database.

When you create a new strongly typed DataSet in the Studio via Data > Add New Data Source, if the data source is an SQL Server database, you get the option to “Enable local database caching”. If checked, Visual Studio will automatically create a Local Database Cache (.sync) file and add it to your project. The code in your DataSet is created using System.Data.SqlServerCe.SqlCexx so that your code can connect to the SQLCE database. It also creates the local SQLCE database (a .sdf file), and adds it to your project.

The key piece in this process is the Local Database Cache (.sync) file. This is what allows you to configure which tables can be cached in your local SQLCE database. If you bring up the Configure DataSet Wizard to either create or edit a DataSet and it won’t allow you to select some tables to be cached locally, you can create or edit the .sync file. The How to: Configure Data Synchronization to Use SQL Server Change Tracking page shows you how to create this file from scratch.

If you already have a .sync file, you can configure it by right-clicking on the file in Solution Explorer and choosing View Designer from the context menu. It’s kind of hidden, but if you click the Add button to add a table (provided there are more tables available in your database that can be added), you will see a link to Learn more about which tables can be cached…, which explains the rules determining which tables can be cached.