Strange database toolbox behavior

I have a simple SQL Server query--SELECT [field list] FROM [in-database view]--that, with a where clause, returns the correct results--a 252 x 17 mixed-type cellarray--without generating a java heap outofmemory error, but without a where clause, generates a java heap outof emory error. If I add code similar to that provided by "Example 3 — Import Rows Iteratively Until You Retrieve All Data" in the help doc for cursor.fetch:

          function data = grabInPieces(~, curs)
            % Initialize result holder and fetch size
              data = {};
              rowLimit = 20;
            % Check for and retrieve more data
              while ~strcmp(curs.Data, 'No Data')
                  curs = fetch(curs, rowLimit);
                  data(end+1:end+size(curs.Data,1),:) = curs.Data;
              end
          end

and have a call to this inside a catch block following the first attempt to fetch, the outofmem error is dealt with, but the result set is drastically abbreviated--down to 8 rows from an expected 320 (which is the number of rows the same query returns in SQL Server Management Studio).

Any ideas?

Thanks, OlyDLG

[Oleg Komarov]

Is the code you posted, exactly what you're using? If not, post the code you're using.

Which MATLAB version do you have?

[David Goldsmith]

Yes; R2011b

Answer 1

[Oleg Komarov]

The code looks correct, unless you're doing something that fetches most of the data (without storing it) before calling grabInPieces().

You can increase the Java Heap Memory: Java Heap Memory Preferences

[David Goldsmith]

"The code looks correct"

Thanks.

"unless you're doing something that fetches most of the data (without storing it) before calling grabInPieces()."

Well, quite possibly I am: as I implied (but I guess didn't say explicitly), before I call grabInPieces, I try to grab it all at once (which has always worked in the past: this problem only cropped up--in extant, heretofore working code--yesterday; the only "environmental" change I can think of is that the amount of data returned by the query may have gone up significantly, 'cause the DB is populated by others); grabInPieces is only called if the attempt to grab it all at once throws the outofmem error. I don't know how DB cursors work, but you seem to be implying that they work soemwhat like file pointers, and that the cursor isn't "rewound" to the beginning of the result set when the error is thrown. So what I'm getting is what's left of the result set after the error has been thrown; that would explain both it's consistent size across runs and pinpoint precisely how many rows I'm getting before running out of memory. Assuming this is the case, is there some way, short of clearing the cursor and starting over, to force a "rewind" to the beginning of the result set? Re-execute the query? (I'd rather keep the "try for everything, grab in pieces if fail" structure, since looping is slow and I don't think the problem will happen very often.)

"You can increase the Java Heap Memory"

Yup, already did that, to the max, and I'm still having the problem. Besides, this isn't an acceptable solution--unless there's a way to do this programmatically and to an arbitrary size--because ultimately this app has to be compiled.

Thanks for your input, it sounds promising.

[Oleg Komarov]

The cursor usually works like a file pointer. However, I am unsure what should happen in case of a Java out of memory error.

I would try to avoid the out of memory by estimating the memory use per row.

You can try to query the meta info of the table with:

Curs       = exec(Connection, Statement);
attributes = get(rsmd(resultset(Curs)));

and establish the amount of rows to import (keeping it prudent).

Then, what you just need is to do a first pre-fetch and keep fetching iteratively but inverting the order of the commands in the while loop:

while ~strcmp(curs.Data, 'No Data')
    data(end+1:end+size(curs.Data,1),:) = curs.Data;
    curs = fetch(curs, rowLimit);
end

Otherwise, you can use a try catch block (but keep the commands in the loop inverted, i.e. first store the results from the previous fetch). However, I am unsure whether the state of the cursor is preserved in the catch part.

Answer 2

[David Goldsmith]

And as suddenly as it appeared, the problem has disappeared: the "where-less" query is no longer throwing a java heap out of memory error. :/

Answer 3

[David Goldsmith]

And now it's back again--any ideas re: how to diagnose this?

[Oleg Komarov]

Well, it could help to know what you do before importing.

[Sean de Wolski]

What else do you have open in ML? Do you have a large *.m files open in the editor, GUIs, etc? How about the current folder, are there many files in there?

I would recommend to try closing the various desktop components you are not using in an effort to minimize your Java heap footprint to see if that helps.