SQLGetData provides an alternative to SQLBindCol to retrieve data from the columns of a retrieved row. It can only be called after calling fetch APIs and when the array size is 1.
As a general rule, SQLBindCol is preferable to SQLGetData. There is less performance overhead; you need to run SQLBindCol only once rather than after every fetch. However, there are special considerations for using SQLBindCol in Visual Basic.
Visual Basic moves character strings to different locations to conserve memory. If a string variable is bound to a column, the memory that is referenced by a subsequent SQLFetch may not place the data in the desired variable. It is likely that a General Protection Fault will result. A similar problem can occur with SQLBindParameter.
Using strings in Visual Basic is not recommended. One way to avoid this problem is to use byte arrays. Byte arrays are of a fixed size and are not subject to movement in memory.
Another circumvention is to employ Windows® memory allocation API functions that are documented in the Microsoft® Development Library Knowledge Base. However, this method involves some difficult programming that is not totally transportable between Windows 3.1 and later releases.
Using SQLGetData rather than SQLBindCol and SQLParamData and SQLPutData in conjunction with SQLBindParameter produce software that is more in keeping with Visual Basic. However, this method involves some difficult programming.