All of a sudden “smt sync” gives me this:
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
DBD::mysql::db do failed: Column ‘SRCPDID’ cannot be null at /usr/lib/perl5/vendor_perl/5.10.0/SMT/SCCSync.pm line 1039.
Update DB (100%)
Error while fetching Product and Repository data.
Downloading Subscription information
Download (100%)
Update DB (100%)
Flagging repositories which can be mirrored
Download (100%)
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:
Visit http://www.suse.com/support and search the knowledgebase and/or check all
the other support options available.
If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…
seems like you’re facing some problem with your database… while the error messages point at a constraint violation during insert (providing no value for a column that is declared “not null” to the DBMS), my guess is that the missing ID should have been read from the database at an earlier stage, but failed.
I suggest to run a check job on the tables of your SMT database.
If that doesn’t help and depending on your setup, you might also try to restore some recent backup of the database. If that’s not available or too old, and if you’d rather keep the content of your current database (server registrations, patch levels etc), I recommend to open a service request with SUSE so that the problems could be identified and maybe corrected manually. But under all circumstances, I strongly advise to first create a database backup so that if anything goes bad, you can still revert to your current state, even if potentially broken.