dennis' blog

I'm not crazy about the way user identities are tracked and connected across different sites these days. This is becoming more and more prevalent.

Actually, that's not quite right. I like the concept, I love being able to log in once (e.g. using my Google ID) and have many sites remember my preferences, history, etc.

The problem is the execution of this concept. In many cases, it's done in very non-transparent ways. It has happened to me more than once now that I posted a comment on a blog or news site, and it just "magically" conjured up a seemingly random avatar and attached it to the post. Now, like many people, I have various avatars and identities. For example, I have one for professional sites related to my job and programming in general, and I have another for (video) gaming, which I use on gaming blogs and sites. It's frustrating and slightly embarrassing when my gaming avatar suddenly shows up on a professional site, without any kind of warning or verification.

Some sites handle identities quite well. On those that do so, my user id and avatar show up on each page so I can see and edit it and sometimes even shows up right next to text I am editing, before I post it. Unfortunately, these sites are still not the norm, to the point that I am sometimes loath to post because I don't know what will happen if I do.

This is the follow-up to The Case for Source Control. It started as a single post, but became too long, so I separated it into 3 posts:

• Source Control and Visual DataFlex 101: The Basics
• Source Control and Visual DataFlex 102: Multi-Developer Use
• Configuring Source Control for Visual DataFlex

Source Control has been discussed in our forums off and on for years and it appears that some developers are not convinced that using it will benefit them. If you are not currently using source control, you should seriously reconsider doing so.

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

I've put together a list of tips and tricks that I hope will help everyone get the most out of the Data Access Worldwide forums.

I attended my first Los Techies/Open Spaces conference this weekend: Pablo's Fiesta.

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!

A big part of our job as software developers is knowing lots of detailed information, but I would argue that knowing how to find information when you need it is even more important. So here is an assortment of resources and tips for Visual DataFlex developers, published today on the DAW Development Team blog.

I played with Visual Studio 2010 Beta 2 over the weekend and I really like many of the improvements.

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.

Don't you hate it when something stops working when you have not (consciously) changed anything in the running environment? I have an application that has been running for over a year in an environment where nothing has changed in regards to the SQL Server, the application, or the network security, other than automatic updates from Microsoft. This is my personal network, so I have full access and control over everything and know what I have and have not changed. As of about 2-3 weeks ago, the Vista clients can no longer access the database.

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.

When connecting from Visual Studio 2008 to an SQL Server 2008 database, Visual Studio allows you to enable local database caching by creating a local copy of the database as a SQL Server Compact Edition (CE) database. This database becomes an embedded database in your project.

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.

See here for product details.