. Under some circumstances, I think that
cleaning may be required if going from a non-debug build to a debug
build.
- Dan
On Wed, Nov 16, 2011 at 6:46 AM, Dan Homerick wrote:
> The message you're seeing is because Microsoft doesn't include debug
> information for their ODBC d
The message you're seeing is because Microsoft doesn't include debug
information for their ODBC driver. This should not prevent you from
debugging entirely, it should just mean that you can't step into ODBC
function calls. If you can't debug at all, then the cause is almost
certainly something besi
2011/11/4 Mateusz Łoskot :
> On 4 November 2011 13:06, David Burken wrote:
>> If you move the includes around on the install then
>> it complicates the include paths when building against the code tree versus
>> building against an installed version
>
> The headers location is already different fo
On Fri, Nov 4, 2011 at 6:06 AM, David Burken wrote:
> Keeping the sub directories allows you to develop off checked out code base
> with one include path. You could do that with flattened path but you would
> have to move the headers in your code tree. I'm all for that but it's
> really not up t
Gdal-dev,
I have a couple questions about the patch submission process. The main
one being, "What is it?" I assume that patches are best submitted
through a Trac ticket. Should we post here for discussion before
opening a ticket, if the issue we'd like to patch doesn't have an
existing ticket open
The current logic for detecting the geometry or geography column will
accept a column of type "image" (a subset of binary string[1]) as the
GeomColumn. Furthermore, the logic checks the column types
sequentially, and will accept an "image" column as the GeomColumn,
even if there is a "geometry" or
On Tue, Oct 25, 2011 at 7:54 PM, Frank Warmerdam wrote:
> On 11-10-25 04:50 PM, Dan Homerick wrote:
>> The ExecuteSQL method returns NULL when an error occurs, or if the
>> statement result is just empty...
>
> The normal approach to distinguishing would be to call CPL
GDAL-Dev,
The ExecuteSQL method returns NULL when an error occurs, or if the
statement result is just empty. I don't see any methods to get
information on the last error, which leaves me wondering if there's a
good way to distinguish the different causes for a NULL result.
I've been prototyping u
