For SQL code, I check now with:
hdl = mapi_query(mid, "very wrong query.");
while( mapi_next_result(hdl) ) {
if (mapi_result_error(hdl)) {
// error handling here
how to do this equivalent for mil queries? Or dont we need mil queries
anymore?
My personal opinion is to keep doing it the old way for mil-type queries
(if (mapi_error()) etc), but that does not seem to work...
--
Arjan Scherpenisse
Centrum voor Wiskunde en Informatica,
Amsterdam, the Netherlands
Because I don't really know if it's a bug on whose side, I decided to at
least put in the issue via this list.
When I try to load the VOC dataset using the JdbcClient with the new
-Xbatching flag, the client hangs when it wants to send its last batch.
I'm batching in chunks of 8000 statements. Research pointed out that
the Java streams are trying to write data to monet, but it simply can't
write it, and locks. I pinned down the problem to be in the very low
level code regions which are outside of the Java reachable scope and go
into the level of the operating system. It just cannot write to the stream.
Monet on the other hand seems to be waiting for data.
When I use a smaller dataset the batching goes fine.
Any clues on what to look for? GDB couldn't help me out much.
Martin Kersten wrote:
> That's a real pity. Would it require many changes?
> Otherwise, we would have to invalidate the perl API
> in the upcoming release.
I dont know if it requires many changes. The reply-parsing code in
monet.pm looks quite 'unstable' to me; I have not found the problem yet.
In my opinion it would be better to base programming language APIs on
the existing libMapi C code. That way protocol changes etc. only need to
be implemented in a single place...
Anyway I do not think I have much time to look further into this, I have
a thesis to finish ;-)
Arjan
>
> Arjan Scherpenisse wrote:
>
>> Martin Kersten wrote:
>>
>>> Does it run against our current DBI?
>>
>>
>>
>> No, it does not run. Connecting works, and executing queries too, but
>> fetching results from queries does not.
>>
>> It is likely that this is the case because it is a pure-perl
>> implementation and it is not up-to-date with some of the changes in
>> the protocol lately.
>>
>> Even the simple test script which comes with the current
>> implementation does not run anymore :(
>>
>> Arjan
>>
>
--
Arjan Scherpenisse
Centrum voor Wiskunde en Informatica,
Amsterdam, the Netherlands