Yes, actually my error is:

>Error. Command name: GET DATA
>(2265) Unrecognized or invalid variable definition.
>This command not executed.
CACHE.
EXECUTE.

>Error # 105. Command name: EXECUTE
>This command is not valid before a working file has been defined.
>This command not executed.
*Define Variable Properties.
VARIABLE LABELS d1 'Record ID'.

>Error # 100. Command name: VARIABLE LABELS
>This command is not permitted before the beginning of file definition
>commands.
>This command not executed.
VARIABLE LABELS d2 'Data di completamento'.

I am using SPSS 16 and my version of limesurvey is 1.72 (5737). I am attching to this message the synthax and data files, and the output from spss

Regards

ITEd, if you can't solve the problem just move everything to the bugtracker.

Thanks for your help!

Helps to focus on the right error

Remove both DATETIME width definitions in d2 and d6 so they read only d2 DATETIME and d6 DATETIME.

I thought this bug was fixed in October (see German thread and related bug), especially for d2 DATETIME23.2 - without width that is the width SPSS creates. Removing the width from d6 DATETIME10 makes it too default to 23.2 in SPSS. There's no data in the variable, so I dont know whether that is correct', but it's more important that the import succeed - the width can be fixed manually if necessary.

Please report a bug that DATETIME variables should not specify a width.

Then the fatal errors are fixed, but you get Warning # 4461.

In Variable Labels d10, 11, 12, and 16 replace all single quotes (apostrophes ' - the fancy ones in "dall’Istituto" are ok) inside the quoted string with two, thus: 'Quoted string''s apostrophes doubled'.

Please report this as a bug. The relevant specs for Value and Variable Labels from the SPSS 16 manuals say:
String Values in Command Specifications
.. Each string specified in a command should be enclosed in single or double quotes.
.. To specify a single quote or apostrophe within a quoted string, either enclose the entire string in double quotes or double the single quote/apostrophe. Both of the following specifications are valid:
'Client''s Satisfaction'
"Client's Satisfaction"
.. To specify double quotes within a string, use single quotes to enclose the string:
'Categories Labeled "UNSTANDARD" in the Report'

I think al the problems are then fixed, but I must admit I'm rushing now to get to the shops for supper before they close.

Regards.

thanks...it worked. I will contact the bugtracker

Antrada: Please post the link to the ticket at the bugtracker or the bug ID.

ITEd: Thanks for this detailled analyses!

In order to follow development on this issue, plese visit BUG ID 02692 at the bugtracker

Variable d6 did not import any data despite abovementioned fixes due to the data's yyyy-mm-dd format. Change the variable definition from d6 DATETIME to d6 SDATE and the data will import correctly. And the width will also be correctly adjusted to 10.

Regards.

@ITEd: If this is important for the bug report please add a comment there, too.

Thanks for your support!

thanks...now the date has been imported....

I've looked into the problem a bit more, and I was wrong to blame the DATETIME width specification for the problem. (I did caution that I'm no SPSS expert, didn't I? )

So:
d1 DATETIME23.2 - is fine, width and all.
d6 DATETIME10 - is wrong: Incorrect variable type definition! It must be an SDATE variable type for the data format of yyyy-mm-dd. The width is fine. "d6 SDATE10" is correct and solves the "(2265) Unrecognized or invalid variable definition" error. (The other fix for Warning # 4461 caused by enclosed quotes remains necessary.)

So why did it sort-of work when the width of DATETIME definitions was removed? Removing the width from d1 DATEIME 23.2 was irrelevant - my boo-boo. Removing the width from d6 DATETIME10 *should* still have caused the error message, but evidently SPSS applies a stricter check of the data format when the width is given. Without the width it gave no error message, but quitely failed to import the data. This is an SPSS issue.

@Mazi: I'll correct/supplement the bug report, but need to update my LS and check 1 or 2 things first.

@antranda: What question type was it that gave the d6 data (INSERIRE DATA)? Am I correct that your survey does not use tokens and is anonymous?

Regards.