Mike,
Our solution also uses the OGR tools and specifically ogrinfo to find out field names from ESRI shape files or MapInfo Tab files. We have been quite fortunate in that we have been able to use the compiled binaries from FWTools (and another thanks to Frank for these!). Unfortunately this method won't work for ArcSDE as FWTools doesn't support ArcSDE. It got me thinking to how MapServer now works with the libmap.dll's for different input formats.
Actually, GDAL/OGR provides the elegant solution to this problem -- plugins. In the latest MS4W, there is a dll called ogr_SDE.dll that when activated by some special environment variables provides the SDE driver to OGR. Frank doesn't distribute the SDE plugin for OGR with FWTools because of the need for an SDK/SDE license, but I have been providing both the OGR plugin and the libmap.dll for SDE for MS4W because I do have access. Note: to use the OGR SDE plugin, you need to be using the GDAL that MS4W provides.
Copying libmap.dll around and doing dll swapping is problematic for a number of reasons, but where we are currently with things like Oracle and SDE support in the Windows binaries for MapServer is much better than where we were before. I don't like this solution as a long term one because it means additional compilation and steps to release the software, and folks can easily become confused as to what exactly they're using. MapServer also supports the concept of plugins, and it is my hope that for MapServer 5.0, we provide the option to build and use the SDE driver as a plugin. All that would be required to use the plugin is the SDK dlls, the plugin dll, and a libmap.dll that supports it. This would simplify the usage of SDE in MS4W even further.
As I don't have client libraries for ArcSDE (but our clients do on their networks) it may prove difficult to rebuild ogrinfo or even MapServer if say I wanted to have a higher MAX_SYMBOLS than the default with SDE support.
I believe MS4W already provides a binary with a higher than normal MAX_SYMBOLS defined. Maybe this limit should be bumped up in the short term until we get dynamic allocation done (5.0 release is the target for this, I think). This seems to be a common request...
My question is this: when compiling with ArcSDE support there is a need for the c header files or similar from ArcSDE. Is there a need for the actual DLL's?
Yes. The header files are included when libmap.dll is compiled and the .lib files are used to link libmap.dll to the SDE SDK dlls.
If there is couldn't an open source dummy set of DLL's with all the external c functions setup be built? This could potentially allow for people to have their custom compiles work and also have a custom version that has been compiled for ArcSDE. Obviously if anyone wanted to query ArcSDE in their development environment they would need real DLL's.
Plugins, in the form that GDAL supports and MapServer supports (but has not yet been implemented for SDE and Oracle) are the solution to this problem. To compile your own plugin, you would need the SDE SDK DLLs, etc, but only one person needs to have that stuff to compile, and then everyone else can use it.
Basically it would be great if one could do things how the MS4W works at present. I think it is great that you can pop a different libmap.dll (and other supporting dll's) into the cgi directory and hey presto you have extra data format support.
MS4W's GDAL has the OGR SDE plugin. This will give you OGR read support from SDE for your data processing needs.
Cheers Mike
Howard
