An ESRI blog post that was posted this afternoon gives us a little bit of insight into some improvements that are coming down the line from ESRI's support staff. This list of improvements includes tools to help ESRI's support staff more efficiently troubleshoot issues and ESRI's new "Bugs Online" service, which was introduced in the plenary session at the User Conference this year. All in all, some very welcome changes.

If you haven't used the online support center lately, you may not have noticed that major improvements have recently been pushed out, including the addition of RSS syndication and more comprehensive search capabilities. Overall these are very welcome changes. One of ESRI's weaknesses continues to be its lack of documentation and transparency, but they seem to be moving in the right direction. Hopefully they will continue to work hard on improving both their internal and external resources.

One much-needed improvement that comes to mind for me is improved user forums. Not many software vendors spend enough time on developing and supporting their user forums (including Microsoft), but ESRI could make just a few simple changes and greatly increase the value of their forums. Also, how about a support wiki? Both of these tools (forums and wikis) are a great way to capture user knowledge and allow users to share their hard-earned experience with others.

Just a thought.

Most web designers know that it's difficult to overstate the importance of page load time. Some studies show that if a page takes longer than 8 seconds to load, a third of users will leave immediately. This factor becomes even more important for "media-rich" websites, and web map sites (and most other sites today) certainly fall into the "media-rich" category. If your site takes a long time to load, you might be losing a large number of potential users who may never come back.

There are tons of tools out there that allow you to analyze a page's load time. I prefer using a combination of tools that include Fiddler and Firefox's FireBug extension.

Don MacAskill, the CEO of the "love of my life" photo sharing site, SmugMug, recently wrote a great blog post about page load time and has promised a detailed followup post (although it's still not out) about how SmugMug's engineers optimize their application's load time. Reading his post made me want to jot down a few of the things that I do to improve load time on my sites. So, here they are:

• Register multiple DNS entries for each site and serve CSS, Images, and JavaScript from these DNS'. This helps get around the HTTP 1.1 limitation of only allowing two connections to a server per browser by tricking a user's internet browser into thinking that it is accessing multiple sites. For instance, for this site, nateirwin.net, I have three subdomains: css.nateirwin.net, images.nateirwin.net, and scripts.nateirwin.net that I use to serve the site's resources, so when a user comes to the site, his/her browser will start downloading the resources from each of the respective URLs without waiting for other connections to close.
• Compress .png files using Ken Silverman's pngout. I add it to the right-click context menu and can then batch compress .png images by selecting multiple images, right-clicking, and choosing "pngout". Scott Hanselman has a writeup on how to add pngout to your context menu. After compression, the images are usually 20-50% smaller. By the way, you can optimize JPEGs too using PureJPEG.
• This tip doesn't improve load time, but it can greatly enhance the user's experience. I like to preload images on a page using CSS. Preloading images is useful when you have images on a page that don't need to display on page load, but will likely need to display after a user interacts with the page (e.g. calling an image from JavaScript). It is key to make sure that something loads initially, and that that "something" draws the attention of the user. While he/she is interacting with that "something", you can continue to load images in the background. Then, once they are ready to further interact with the page, the images will be waiting for them. How do you do it? Well, it's incredibly simple:
• Add a style class element to the header of your page called "preloadPic" and set it to display:none.
• Then add the images to the bottom of your page and define their class "preloadPic".
• A lot of the web applications that I work on (especially the web mapping applications) rely heavily on JavaScript. Unfortunately, because of the complexity of the JavaScript these files can be pretty hefty to push out to the user. Before I deploy JavaScript to a web application, I run it through an optimizer that removes comments, whitespace, and other unnecessary characters. I like to use the web edition of JSJuicer, although there is also a command line version that you can use. You can save up to 50% by doing this, which can have significant ramifications in how long it takes a page to load. This smaller size also makes the application more responsive, as browsers have to interpret JavaScript code.
• I also like to combine/aggregate CSS and JavaScript as much as possible, as minimizing the number of HTTP requests is one of the best ways to improve performance of a web page. There are, however, obviously times where combining these files is not possible. In this case, I try to make sure that only the CSS and/or JavaScript that is needed is sent to the browser.
• Bundle images to decrease the number of HTTP requests. This is especially useful for web map applications, as they often have a large number of icons that are of the same format (.png, etc.) and are the same size. Bundling images basically means that you create a single image that contains all of the necessary images and then use css to display the needed individual images off of that image. This allows a single image to be downloaded, which minimizes the number of HTTP requests. I am just starting to look into this optimization, but am *very excited about the possibilities, as this should help eliminate - or at least reduce - delays in an application's startup time. The Google Web Toolkit (which is, by the way, a great resource for anyone who is developing AJAX applications) has image bundling built in, but you can also do it fairly easily yourself.

These are just a few of the things that I do to optimize page load time for my sites. You can take this optimization as far as you want. Some other methods include streaming JavaScript to a browser, using CSS sprites, and optimizing your resources for maximum caching. Keep in mind, though, that these types of techniques (including the techniques that I discussed in detail above) shouldn't be applied without first analyzing your application and understanding how the technique(s) will impact the resources on the site. They are not meant to be applied in every instance.

Conclusion: These techniques, if applied in the right circumstances, can greatly enhance a user's experience. If applied in the wrong circumstances, however, they can cause unintended consequences.

Helpful Resources:

• AJAX Performance Blog
• Google Web Toolkit Blog
• Yahoo! User Interface Blog (here is a link to an especially helpful series of blog posts)

[ASIDE] I've said it before, and I'll say it again: If you're looking for a photo sharing site, I *highly recommend looking into SmugMug. In my opinion, it is, by far, the best photo sharing site out there. The SmugMug team is revolutionary in both how they run the company and in how they embrace new technologies to help enhance the service that they provide. This much, at least, is immediately obvious when you start using their site. If you'd like to support my Smugmug account - and, of course, this blog, click on the Smugmug banner just below. You'll be able to sign up for a free 14 day trial (without even giving them a credit card!).

This past week, ESRI released several new white papers. The one that I'm most interested in is "An Overview of Distributing Data with Geodatabases". This is the white paper that was promised during the "Managing Distributed Data with Geodatabase Replication" session at the ESRI 2007 UC.

The first several pages are full of the now obligatory replication/synchronization diagrams which, while maybe helpful to some, I've seen at least a hundred times now. The post then, however, goes into the guts of the different techniques, including geodatabase replication, DBMS replication, and simple copying and loading of data. Here's a quick summary of each technique:

• Geodatabase replication replicates data from a source (parent) geodatabase to a destination (child) geodatabase and creates the infrastructure to allow for tracking and synchronization of changes. Geodatabase replication is fairly powerful; it allows parameters to be defined that restrict the data that are replicated. At 9.2, geodatabase replication can only occur on SDE geodatabases, but at 9.3 SDE geodatabases will be able replicate one-way with a file or personal geodatabase. There are different types of replicas, including check-out/check-in, one-way, and two-way.

Developers can work with replicas through the GeoDatabaseDistributed ArcObjects library components. If you just need coarse-grained access to the geodatabase, you can use the GeodataServer object model. If you need more fine-grained access, however, you will want to use some of the older ArcObjects object models which allow you more capabilities but restricts you to working with geodatabases that live on your Local Area Network.

Geodatabase synchronization can be automated using the synchronize changes geoprocessing tool (create a Python script, call it from a script (.bat or otherwise), and schedule it using Windows scheduler).

In cases where large amounts of data are stored in a geodatabase and need to be moved to a remote office and synchronized, it may be best to detach the database from the parent, send it to the child (mail it, etc.), and then reattach it. You can then use the 'register with existing data' tool to create the replica.

• DBMS replication is good for replicating an entire geodatabase to a read-only geodatabase in a connected system. Therefore, this is a good option for load balancing and fail over. The major limitation is the inability to choose what gets replicated.

To setup and use DBMS replication, you must first understand how a geodatabase interacts with its underlying database.

• Data copying and loading is the "low-tech" way of setting up replication between multiple geodatabases. There are multiple geoprocessing tools available to help automate and schedule this process. Using this method, however, there is not a great way to verify data integrity during the replication. You can write your own code to avoid redundancy, but this is a lot of work compared to just using one of the other replication techniques.

This white paper didn't go as in-depth as I was hoping for. It does, however, tie the concepts together, and it contains links to other helpful resources. We've been using one-way replication successfully for a while now, and are looking to setup several two-way replicas with some remote offices here shortly. I'm sure you'll hear back from me about our experiences.

Here are a couple of other resources to help you learn more about distributed geodatabases. The technical brief is especially useful:

• Link to the "An Overview of Distributing Data with Geodatabases" white paper
• ESRI's "Geodatabase Replication: An Overview" Podcast (link to transcript)
• ESRI Systems Integration Technical Brief: "ArcSDE Geodatabase Replication Overview"

ESRI has announced that ArcGIS 9.2 Service Pack 3 will be released later this month, and have listed the issues that are addressed in this set of patches.

I only scanned through the "issues addressed" for ArcGIS Server .NET. Here are some of the highlights (for me, at least):

• NIM008691 - The Web ADF generates a callback response that updates the same TOC node multiple times. (This is good, but wasn't this problem addressed with the interim TOC patch?)
• NIM008846 - When blending services with ArcGIS Online services and not using the Web Mapping application, the services may not display correctly at the initial extent. (Yep, definitely noticed this problem. I've thought that I've fixed this problem several different times, but it seems to continue to pop up. Glad to hear it was a bug, and not just me.)
• NIM009378 - A number of significant changes have been made to improve discussion topics related to ArcGIS Server .NET development. This is an updated version of the ArcGIS Server .NET Developer Help for 9.2 SP3. (Good to hear.)

There aren't nearly as many fixes as there were with Service Pack 2, but there weren't nearly as many fixes needed after Service Pack 2, so it kind of makes sense. I've said it before, but I'll say it again: Overall, I've been impressed with the stability of ArcGIS Server after the release of SP2. There are still some issues that need to be addressed, but,  in my opinion, it is getting to be a fairly solid product.

I'm just hoping that with all of the promised new functionality coming out in the 9.3 release it will be a more solid product from the beginning. We had some major headaches working with the initial release of 9.2, and I'd really like to avoid having to go through that again.

Note: This is the second entry in a series of posts titled "Web Mapping Offerings Compared". The first post, Introduction, is available for viewing here.

Introduction

As I mentioned in the first post of this series, many of the online mapping services offer developers application programming interface (API) hooks into their services. These entry points allow developers to build applications that utilize both the data and other bits of functionality that they offer. Over the last couple of months, in my search for web mapping solutions for the organization that I work for, I have experimented with many of these APIs, and, as I worked with each of them, I noticed that each seemed to have its own unique set of strengths and weaknesses. It seems that while each of the products are moving generally in the same direction, they are all trying desperately to separate themselves from the rest of the pack while also working hard to attract developers. This can only be good for us (as the consumer, of course, but also, more importantly for me, as the developer), so I'm certainly not complaining, and as more levels of functionality are opened up to developers, I imagine that we will begin to see more "GIS-centric" applications built on top of these APIs (in place of the all-too-common 'mash-up').

The *current bottomline, though, is that these APIs don't offer nearly as much built-in functionality as a full-featured GIS web map application. Out of the box, they don't support as many data types or allow you to directly query associated attributes, etc. So, the major question is "why would a GIS professional consider using an API when he/she has access to a full-featured GIS web map platform?" Well, the answer is simple - at least for me.

I've noticed that often, although we (as GIS developers) hate to admit it, users of web map applications really only need the most basic of functionality. Although we'd like to think that all of our users need the ability to perform complex queries and analyses on our datasets, this level of skill is the exception and certainly not the rule. Now, I'm obviously generalizing here, but I'm speaking from the experience that I have within my own organization. There are certainly times where a level of advanced functionality is needed, but I would say that in about 80% of our use cases the user just needs to be able to:

• View data laid over high-quality (and high-performing) base data
• Digitize and attribute simple geometries
• Perform some fairly basic attribute queries

If this is the level of functionality that you're looking to achieve for your web map application(s), an API may be the way for you to go. And even if you need more functionality you may want to check back as this series progresses, as somewhere in the series (I haven't decided where I'll fit it in yet) I'll talk about ways that you can integrate other technologies with some of the existing API features I'll discuss to build your own web map application that rivals the offerings and functionality of one of the more full-featured GIS web map platforms. And the cool thing is that you can build a very lightweight but powerful application using this type of model.

Following are the criteria that I'm going to use to evaluate each of the APIs:

Type, Breadth, and Quality of API(s)

All of the products that I'm going to review in this API section have at least a JavaScript API that allows developers to hook into their services. A few, however, have more API offerings. This was definitely a consideration for me when looking into each of them, as different APIs meet different needs. It's pretty easy for me: the more options, the better (assuming, of course, decent quality and stability).

Kind of along the same lines, if a product's API(s) don't include the functionality that I need in my application, I'm not going to use it. Some of the APIs are more mature than others, and it shows when you start getting your hands dirty.

Accessing Data/Services (Licensing)

One of the biggest concerns/questions that I had when I first started looking into the different data/service mapping APIs had to do with licensing. If the cost or terms of use were prohibitive up front, it wasn't worth my time to spend a lot of time researching (read: playing) with the technology. Luckily, I found that the aforementioned competition in the fight to win developers and users over didn't stop at innovation in the products themselves; it also trickled down to licensing models. To put it simply, not only are the different players trying to outpace their opponents in their pricing models, all are also making their services available for free - with some limitations, of course.

Now that I've gotten all of that out, I'm going to immediately renege on one of the statements (well, I'm not really backing away from what I said, but it may seem like it on first read): While the different vendors are trying to compete on pricing, when it comes down to the licensing model that they use, they are remarkably consistent. They all use the same type of model, based on transactions, to track and (if necessary) price usage of their services. Most say that a single transaction equals nine 256x256 pixel tiles (although there are exceptions to this), so, if you pan and only have to load three more tiles during the pan, this is considered 1/3 of a full transaction.

The good news is that most of the vendors allow developers to use their services for free - up to a certain transaction limit - as long as the application is public-facing. If the application is, however, on an internal network you must purchase the data from the vendor.

Quality of Base Data

As I mentioned in the first post in this series, Introduction, one of the things that drove me towards this search was the fact that we needed to be able to use high-performing, high-quality data in our applications.

While not all of the APIs that I'm going to discuss serve their own data, the data that they use have to be served from somewhere. So, if an API wasn't built on top of a particular data service (for instance, Open Layers), I had to know what data services it could connect to, out-of-the-box, and how good the data that it could access were. For those APIs that were built on top of a particular data service, it was important for me to know how good the default data were.

Built-In Features and Data Support

While all of the APIs support a "core" level of functionality, there are certain features that set some apart. Sure, they all allow you to view data and navigate around the map, but can you easily build digitizing functionality into the application with the API(s)? Can you access the product's geocode and routing services (and this question ties back to the licensing issue)? These are the types of features that I needed for my applications, and, therefore, the types of questions that I considered when researching the different options.

Another key metric that makes it easier to distinguish between the different APIs is their out-of-the-box support for data. All of the different products allow you to create and manage shapes within a user's session, but they don't all give developers the capability to import different types of data into an application. Now, to be fair most of the products only currently support a few different types of data out-of-the-box. I imagine, though, that this will change over the next six months or so, as many of the vendors seem to be focusing more of their efforts on this critical issue.

Ability to Integrate with a GIS

Unfortunately, I couldn't just throw out my organization's GIS needs when looking at the different APIs (and I say unfortunately because, if I could throw these needs out, it would make my life a whole lot easier). I had to consider GIS-type issues like projections, accuracy of base data, and resolution of imagery (and this was especially important in some rural areas, as many of my organization's units aren't anywhere close to an urban area).

Not all of the applications that I'm working on require true GIS functionality, but this was an important consideration, nonetheless.

And Moving On...

In the next post, I'll start reviewing the APIs using both the overarching criteria that I laid out in the Introduction post and the API-specific criteria that I laid out above.

Note: I've received several requests to look at products that I didn't explicitly mention in my first post. I will do my best to get to know all of them, as I'm curious to see what's out there. It will take some time, however, so please forgive me for any delays.

Brief Introduction

Microsoft's ADO.NET team recently released a new project, as a Community Technology Preview (CTP), through Microsoft's Live Labs. The project, codenamed "Astoria", is a technology that allows developers to easily build and deploy data services (either on their own servers or to Microsoft's hosted "Astoria Online Service") that are accessible to applications through HTTP requests. This idea is not necessarily new - there are other ways to build a web services interface - but the ability to easily build a data service for SQL Server that is accessible through HTTP is definitely groundbreaking.

As the "Astoria" site preaches: this type of service is especially useful for AJAX-based applications that work hard on improving the user experience, through the use of Flash or Silverlight. Once an "Astoria" data service is published, you can query the underlying data structure by passing parameters in the URI. For example (and this is taken from the "Astoria" Overview document that is available on the Live Labs website):

 

To access all customers in a database:

http://myserver/data.svc/Customers

To access a customer whose key is "ALFKI":

http://myserver/data.svc/Customers[ALFKI]

To find all orders that are associated with a customer whose key is "ALFKI":

http://myserver/data.svc/Customers[ALFKI]/Orders

 

And so on, so forth. You can get much more focused than the above examples. You can drilldown into related data, filter out records, sort records, and even page records.  You get the picture, right? It really is a powerful way to interact with a database.

How does "Astoria" make it so simple? Well, when you build an "Astoria" data service with Visual Studio (and, by the way, you need Visual Studio "Orcas"/2008 beta 1 to install the "Astoria" framework and build these types of data services) you build an Entity Data Model (EDM). "Astoria" then uses this model to wade through the underlying database and figure out how data are related. It can then use this simplified information to serve the data and make them accessible through the RESTful interface. "Astoria" can currently represent data in XML, JSON, and (as Pablo Castro, Microsoft's ADO.NET technical lead, mentions in a really great presentation that he gave at MIX 2007) *very experimentally in RDF+XML. XML support is probably the most accepting, but JSON is, of course, perfect for use with AJAX applications.

Helpful/Interesting Resources

I find "Astoria", and the underlying concept of taking complex data and making it broadly accessible intriguing. Again, I understand that this is not new territory. SOAP and other web services are a more powerful way of accessing data, but I see "Astoria"'s restful interface meeting the needs of many. The ability to easily publish a database and make it accessible to the web is something that will allow many developers to build richer (and lighter-weight) web (and mapping!) applications.

• Project "Astoria" Homepage
• Pablo Castro's "Astoria" Presentation at Mix 2007
• John Udell's "A Conversation with Pablo Castro about Astoria's RESTful Data Services"

I haven't (yet) had the chance to experiment with the June Community Technology Preview (CTP) of Windows Server 2008, previously code-named "Longhorn", but was excited to read that a server core role has been added for IIS7. If you haven't played with or read about any of the features included in Windows Server 2008, I'll catch you up on one of the ones that I'm most excited about: the ability to run Windows Server 2008 in a stripped-down, lightweight, and extremely focused mode. Microsoft is calling this new feature, which is basically a set of new operating systems, server core.

When running a server core, you are setting up an operating system to perform a single task, and are not installing any unnecessary features. This not only increases the stability of the operating system and lessens the load on the supporting hardware, but it also makes the machine much less vulnerable to attacks and makes maintenance (e.g. applying patches) on the machine less burdensome. And, best of all, there's no overhead of having a graphical user interface and features that you never use running.

With the release of the June CTP, IIS7 has been added as the seventh supported server role. As a web developer, this is the server role that I'm most excited about, although there are others available, including file server, domain controller, DNS, DHCP, and network load balancing.

One big problem remains, though (and I hope this is taken care of before or in the final release): Because of the lack of managed code support in server core, IIS doesn't currently support ASP.NET when used on server core. If this problem is taken care of, I can see us utilizing server core on virtual machines and increasing the performance of our servers while also increasing the number of instances each of our physical servers can support.

ISC announced on the 2nd that it has released MapDotNet Server 2007 6.1. This version of the mapping platform includes some major enhancements, including support for the newest Virtual Earth Map Control, v5 (which, in and of itself added quite a bit of functionality and hooks into the API, especially in its support for shapes). As I've mentioned several times before, I've been impressed with the quality of the data being served through Virtual Earth, and am expecting that things will only continue to improve (you may have noticed that Virtual Earth just released a major data update in the last couple of days). It also looks like ISC has worked hard in this release to improve performance on their end; they are touting 5-12 times the performance in this release when compared to 6.0. The new version includes tile pre-caching in SQL Server and a tile pre-loader utility. Performance of SDE data laid over Virtual Earth wasn't bad in the 6.0 release, but there was definitely a difference in load times, at least on our hardware and geodatabase(s). Hopefully these improvements will make the difference less obvious, although I'm sure that there will always be some latency when compared to data coming from Microsoft's servers.

In addition to these enhancements, ISC has also made some improvements to other parts of the MapDotNet Server product, including:

• New support for Virtual Earth 3D, including a new template that  allows out-of-the-box 3D functionality
• Easier connection to ArcSDE
• Support for SpatialDB, a SQL Server 2005 spatial extension

They also have plans to release an Interactive SDK sometime this month, and it looks like they've made some recent additions to their support WIKI.

All in all, these are all welcome additions, and I'll be playing around with the new version soon.

Online mapping is taking off in a big way. Just look at the number of online mapping sites now available (Ask.com, ESRI, Google, Mapquest, Microsoft, and Yahoo! are the ones I can think of off the top of my head) and, especially, at the work and money that's being put into enhancing these applications and the data that they serve, and you'll see that mapping - albeit in a simple form - has truly become an integral part of most people's everyday lives. These products all have their own way of doing things, although there are obvious similarities between them all. Now the rush is on to see who is going to provide the best - and most open - application programming interface (API) and licensing model.

Over the last couple of months, I have worked to develop prototype applications with several different web mapping APIs, including ESRI's, Google's, Microsoft's, and Open Layers'. My goal when initiating this development was to get a feel for the strengths and weaknesses of each of the offerings, and, in the end, to decide the best route for my organization. In addition to working  with each of the APIs alone, I also worked with (or at least discussed in length with the vendor(s)) some third-party products that allow you to tie into the data offerings of the large online mapping vendors while working directly with databases on the backend. Through the process of learning these new technologies, I discovered quite a bit about each of them, and feel like I now have a pretty good understanding of how they compare.

Before I delve into each of them, here's a bit of background to help frame this series of posts: My organization is pretty much a strictly ESRI shop. Our current architecture sits on a Microsoft/ESRI platform, so we really only use SQL Server, ArcSDE, and ArcGIS Server. When ArcGIS Server 9.2 came out, we decided that we were going to use it exclusively for our web map applications, as it tied seamlessly into our existing infrastructure and expertise. Well, we initially ran into the same problems that everyone who used the Web ADF ran into (some of which a lot of developers are still running into - see the ArcGIS Server Forums) and were a bit discouraged by the lack of quality, documentation, and - most importantly - response from ESRI. We weren't dissuaded, though; we kept at it, trying to build tile cache after tile cache after... Granted, we were trying to build massive tile caches, but we figured since ArcGIS Server was an enterprise product, it would be up for the task. From our experiences, I can now say that we were wrong. There was only minimal documentation available initially to help us in our massive cache builds, so we had to learn each lesson the hard way. In addition to this, the product simply didn't work as advertised. Even with quite a few fairly powerful servers dedicated to building cache for weeks at a time, a lot of times we couldn't get the processes to successfully complete, and had to either start over from scratch (as there is still not a good way, at least that we're aware of, of picking up a failed cache build where it left off) or give up all together.

In this context, with lots of frustration and a bit of regret, we made the decision to widen our vision to other web map products and/or data services, as we needed to find a way to include high-quality and high-performance nationwide base data for our applications. In doing our initial research, we considered a couple of important requirements:

1. Ability to Plug-in to our Existing Infrastructure
2. Performance
3. Cost
4. Quality of User Experience
5. Ability to Support Open Data Types
6. Scalability

After considering these requirements, we settled on a number of possibilities, including:

• ArcWeb Services
• Google Maps API
• GeoServer
• MapDotNet Server
• Microsoft Virtual Earth API
• Open Layers API
• Visual Fusion Server

Now, you've probably noticed a couple of similarities in these different products. First of all, many of them are free-to-use (unless you use their data internally, of course, or go over the usage limits that they have specified (that is, in the case of using data served by either Google or Microsoft)). ESRI ArcWeb Services, MapDotNet Server, and Visual Fusion Server are the exceptions to this first rule. Second, each of them have the ability to access high-performing data that are served from either Google or Microsoft. This was probably the most important requirement to us, as we realized while trying to build our tile caches for ArcGIS Server that there was no way our organization could sustain the practice of maintaining huge datasets and building massive tile caches, and that, even if we did get a cache successfully built, we would never be able to meet the performance expectations/needs of our users while serving the data from our infrastructure. The last common thread between the products is the fact that they all support open standards, albeit some more comprehensively than others. This was another absolute requirement, as, like many other organizations, we are trying to move in the direction of open standards.

In the series of posts that are soon to follow, I will discuss my experience with these different products, focusing on the requirements of my organization and how well each of the products meet these requirements. This may be helpful to others, as our requirements seem to be shared by many others out there.

I work with DataSets a lot in ASP.NET, so I was very surprised when I added a new query to an existing TableAdapter and got an error "Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints" from the new query. I knew that the query was fine, as I executed it with set parameters and received the expected results. I even tried setting EnforceConstraints to false on the dataset, but still no luck.

Then I found a remarkably helpful blog post on this very same error. Well, to clarify: the blog post (which was really more a plea for help than anything else) didn't help me much, but the comments had a ton of suggested solutions. I slowly picked my way through them, one by one, working through some and skipping over others. I finally found a solution to my problem at the bottom of the page.

The schema that was returned from the suspicious query didn't match the schema returned by the TableAdapter. The solution was to create a new TableAdapter that returned the same schema as my query. After that, everything worked as expected.

The thing is, I never received an error message when adding the new query to the TableAdapter, and the behavior doesn't seem consistent at all, as I have several other TableAdapters that have multiple queries which return different schemas. So, I'm still looking for a *real solution (if it exists). This is one of those frustrating problems that I'd really like to get my arms around.

Anybody else dealt with this?