Hi Erik_Inn,

I can't replicate this problem, but I also don't use MS SQL. Are you able to access your database directly? If so, can you see if there is a table in your limesurvey database called "lime_survey_links"?

Thanks, Jason

Hi jcleeland,

Thanks for your response. No, I don't have access. But I have contacted the one who does have direct access to the database. I'll let you know whether or not there is a table called 'lime_survey_links' asap.

Greets,

Erik

Hi jcleeland,

There is a table called 'Dbo.lime_survey_links' in our LimeSurvey database. This table is empty.

Greets,

Erik

Hi again Eric, and apologies for being offline for so long.

Could you have a look in the tokens table for your survey? ie: if it's survey id 12345, the table called "lime_tokens_12345". The error message you are getting says "[SQL Server]Invalid column name" followed by the UUID (participant_id) which implies that the appropriate columns/fields do not exist.

I suspect it's in the tokens table, caused by updating. If you've updated an older version of LimeSurvey, this upgrade is supposed to create a "participant_id" column in your existing tokens tables, but if not this error would occur.

Jason

Is this still an issue or is it fixed in build 121204

Sorry, it is not fixed in build 121211 :-(

I think it has nothing to do with an update, my installation was new.

As I described in 06996, it seems to be caused by wrong JOIN parameters:
LEFT OUTER JOIN [...] ON ([...]."attribute_id"=[...]."attribute_type")
(integer = character => BUMM ;-))

I was to stupid to find the place, where the relationships are defined and the SQL is built :-/

@i_meyer i have seen that in pgsql database. there should be a table participant_attribute_names, that table has a primary key that consists of two fields: attribute_id and attribute_type

to fix your problem, you need to drop the index, and add it for only the field attribute_id

can you confirm that solves the problem?

Hi,

Today I have updated to version 2.00+ build 130103. Problem solved. Thanks a lot

I updated to build 130103 (no new database), problem was still there.

As you suggested, I tried:

alter table participant_attribute_names drop constraint participant_attribute_names_pkey;

and

create index on participant_attribute_names (attribute_id);

and now it works. Thanks a lot.

Composite primary key issue is only on pgsql. The fix will be attached to original report 6996

closing this one as already fixed