From the feedback we've gotten so far, it seems that after MySQL, SQL Server is probably the most popular request. So it will probably be the next connector to implement. But I think we'd like to get a better sense of the commercial and technical viability of the A-Shell/SQL concept first before deciding whether to focus development resources on improving the general design of the connector interface, versus towards creating new connectors.

Unfortunately, despite the commonality of SQL and the modularity of the SQL.SBR connector interface, creating a connector for a specific database is still a non-trivial undertaking, so we don't want to rush into it without a good sense of what we're getting ourselves into.

One aspect of SQL Server that it makes it somewhat more complex to deal with than MySQL, is that it is more of a family of related databases. The fact that MySQL has been free and largely upwards (and cross-platform) compatible has led to a situation where nearly everyone is running the 5.x version. But in the case of SQL Server, the combination of the licensing costs and more complex compatibility issues (even though it's just the Windows platform) has led to a situation where it isn't quite clear whether we should target SQL Server 2008, 2005, or 2000; nor what all the consequences and trade-offs would be of such a choice. There's also the question of whether an SQL Server interface ought to support Access.

If you follow the GUI-related posts, you'll notice that we are still getting hit with W2000 compatibility issues, so it's not just a theoretical problem.

It may be (and I hope it is) that we can target a lowest-common denominator without giving up too much, but from a development logistic perspective, it is difficult to start new development using old versions (of the SDK, tools, database, etc.). Working with new versions, on the other hand, it is often easy (possibly even by design) to overlook backwards compatibility issues.

All of which is to say there's homework to be done. As always, feedback is welcome, and in this case, we'll probably need a lot more of it before starting development of the connector.

The security aspect of an SQL Server connector would be enough to really hurt anyone's brain and I suspect producing something like that and not complying with the security specification is not a good idea.

From a version point of view, I suggest 2008. It is already a year old and there is a free version with Reporting Services. And I think, to write a fully compliant connector, it has to be backward compatible!

The compatibility issue is something I need to study, but if it's true (i.e. that a compliant connector has to be backward compatible), then perhaps the "which version" conundrum is not as bad as I feared.

I seem to recall hearing the occasional complaint from users with multiple applications all using SQL Server, where one application vendor insists on SQL Server version N, while another insists that they can't go beyond N-1. But perhaps that's the reverse of what you're saying, i.e., the an application/connector might not be upward compatible, but it should be backward compatible. Which would be a very strong argument for targeting the 2008 version. Not to mention the free version.

But as for the security problems introduced by SQL, indeed, it's an economic stimulus package in itself, given that you almost need a dedicated security administrator for every handful of files. But unless I'm overlooking something (which is quite likely), isn't the issue primarily driven by the desire to open up access, rather than SQL or the existence of the connector per se? I mean, if you want to be able to say you have your data in SQL, but lock it down just like our current proprietary data, then just limit access to an application pseudo-user whose password is only known to the application (i.e. perhaps based on a formula). OK, so even that doesn't stop a root-privileges administrator from granting himself, or anyone else, ALL privileges. Still, that responsibility is squarely in the lap of the customer or site administrator and more or less on the same level as keeping the root UNIX password secret.

Where it really gets sticky is when you start defining all kinds of access levels, based on individual fields, user classifications, views, etc. (Which of course is what management wants.) That's when you need the full-time security analyst/administrator. (Which of course is what management doesn't want.) Is it too late to turn back now? We could always try for PSQL (Proprietary Secret Query Language) instead. But I guess we already have that - we've just been calling it RANDOM files.