cancel
Showing results for 
Search instead for 
Did you mean: 

Training an SVM on table with schema flexibility fails

Former Member
0 Kudos

Dear colleagues,

I'm trying to train a Support Vector Machine on a table with schema flexibility.

On a small test table with only a couple of columns both the training and the prediction using the PAL libraries work fine. However, on my large sparse table with more than 1000 columns and "schema flexibility" set at creation time, I constantly run into the following error:

Could not execute 'CALL SYSTEM.AFL_WRAPPER_GENERATOR ('PAL_SV', 'AFLPAL', 'SVMTRAIN', PAL_SV_SIGNATURE)' in 30 ms 529 µs .

SAP DBTech JDBC: [423]: AFL error:  [423] "SYSTEM"."AFL_WRAPPER_GENERATOR": line 32 col 1 (at pos 1346): [423] (range 3) AFL error exception: AFL error: registration finished with errors, see indexserver trace

The indexserver trace gives me something strange like:

AFLPM_SQLDriverObj.cpp(02439) : aflpm_creator : direction must be in or out

As far as I see it, all parameters are fine, though.

Is there a limitation that does not allow PAL functions to be executed on tables with schema flexibility? I suspect so, because I'm running into similar problems with the SUBSTITUTE_MISSING_VALUES function.

Thanks for any help,

Daniel

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hey there,

isn't there anyone who came across this issue? I'd love to know if this is a known technical limitation with tables that use the "schema flexibility" or rather a bug. In the former case, can anyone suggest a workaround?

I'd be grateful for any help or any pointer to further documentation.

Best,

Daniel

Former Member
0 Kudos

Hi Daniel,

I do not know if it is really related to your problem but I have see a column limit of 1000 when using PAL SVM. Until now I have not found a good way to work around that limitation.

Cheers

Christian

Former Member
0 Kudos

Hi Christian,

thanks for your reply. It's also my assumption that 1,000 columns is a strict limit for these functions. Too bad, though.

Best,

Daniel