[Fwd: Re: [Harbour] SF.net SVN: harbour-project:[14022] trunk/harbour]

[Viktor Szakáts]

Hi Mindaugas,

(resent to public list)

> here I forward a letter I've send today, but it has not yet reached mailing list.
> 
> I've looked a little deeper into OCI functions. I've not understood the idea of additional lib. Oracle offers oci.dll and OCI*() functions. ocilib is developed on the top of this Oracle Client Interface. ocilib[x].dll offers OCI_*() functions.
> 
> Why this additional level is required? Why not to use OCI*() directly?

First I just followed this past suggestion that popped 
on the list. Then I realized how it worked and saw the 
potential to use oci dynamic lib directly.

Ocilib advertises itself as easy to use and fast interface 
to Oracle dbs, which is highly portable and also supports 
several Oracle client versions with the exact same 
interface. As such, I believe its main purpose is to hide 
the platform and version differences, and the nuisance of 
the original Oracle API, which looked quite terrible when 
I looked at it considering accessing it directly.
But, how can a wrapper be also faster? Well, I _guess_ 
because it uses the Oracle API in an optimal way.

See this also:
  http://www.codeguru.com/cpp/data/mfc_database/oracle/article.php/c15189/

Nevertheless, it would be _great_ to have an sddora lib 
with direct Oracle API access. But I'm sure it's a little 
bit bigger exercise than this one.

[ BTW, I also don't need Oracle for my projects, but it's 
a cool thing, so I just felt like doing it. ]

[ BTW2: My oracle server is still running and accessible 
from the outside using the method I've sent to you. ]

>> + contrib/rddsql/sddoci/sddoci.c
>> + contrib/rddsql/sddsq3/sddsq3.c
> 
> Thank You, for you new SDD. I've started Oracle development some time
> ago, but never fixed because lack of time, motivation (I do not need it
> for my own projects), and test environment. I see you current code is
> much more complete, than my. It also uses some more nice API than I was
> trying to use. I was using OCI*() functions (not OCI_*()), i.e.
> OCIHandleAlloc() was used to allocate server, context, environment,
> error, and session handles. It seemed very stange...
> 
> BTW, in the OCI*() API, transaction management is done using API
> functions, but not 'BEGIN', 'ROLLBACK', 'COMMIT' queries (like in
> MySql). If this is also true for OCI_*() API, perhaps we need to SDD and
> introduce new methods. For MySql and similar "query based transactions"
> we need to do queries on transaction method calls.

I guess you're right:
  http://orclib.sourceforge.net/doc/html/group__g__transac.html

>> ; TOFIX: To Mindaugas: Current SDD architecture will crash with GPF
>>          if dbUseArea() is attempted after a failed RDDI_CONNECT
>>          call. You can check it f.e. with sddodbc's test1.prg, by
>>          modifying test.mdb to test_.mdb, and simply run it.
> 
> I've tried to, but I guess you've already fixed it. But I see a lot of
> "?" characters in test1.prg table browse (in BCC). Something wrong with
> UNICODE support, though I do not see error code. Maybe some hidden
> #define UNICODE exists...

I hope I fixed it, yes. It was an unchecked pointer, but 
I'd appreciate if you could look at it, maybe there exists 
a better fix.

> !!! This "&& 0" is dangerous, not compatible with next #if defined

It was a temp mistake in commit. You tested just this 
wrong version, hence the '?' chars I guess.

BTW, I was also experimenting with Sybase db access (which 
I could use in a project, to avoid ISQL external calls), but 
after spending a few hours on it, I couldn't even attach to 
a local server. I tried with FreeTDS, but I also failed with 
plain Sybase isql.exe. (there is another implementation of 
isql.exe which works properly, but it uses some other APIs, 
which I don't know anything about).

Brgds,
Viktor