> > In the meantime you can try using a splitter regexp that also removes > > white-space. Try something like \s*\t\s* instead of just \t. I have not > > tested this but it might be enough to make it work. > > I guessed there would be a neat trick like this, but couldn't think of it last > night. > > However I tried \s*\t\s* > and "?\s*\t\s*"? which also needs Block = \"Block\ and Flags = \Flags"\ > > and they both oddly give the same error as before: > Error: Item not found: Reporter mismatch: The feature has reporter 'demorep2' > whereas you have given 'demorep2 ' on line 6: 1 2 1 "demoB" "de... >
Ok, I checked your example data again and found that there are quotes around the values and the space is inside the quotes. This makes it more problematic since the splitter regexp also removes the quotes between the values, but not the first and last one one the line. I still think it is possible to create a regexp that can do the work but I am afraid that it will not be very simple. I think we need a "trim whitespace" option that works similar to the "remove quotes" option for the importer plugins. > > This problem is affected how the database handles strings. MySQL is > > case-insensitive. Postgres on the other hand is case-sensitive and the > > same problem would never have appeared. The important question is if the > > "demoblank" and "demoBLANK" should be treated as the same reporters or not? > > > > In Postgres they are already treated as different and it would be rather > > hard to change that. The only way is to convert all ID:s to the same > > case before storing them in the database. > > > > In MySQL they are treated as the same and it is equally hard to change > > that. The problem appears here because the two reporters are in the same > > file. If there had been two different raw data files, both "demoblank" > > and "demoBLANK" would have mapped to the same reporter. The bug in our > > code is that when the lines are in the same file we do case-sensitive > > comparison to check what has already been inserted. I'll add a ticket > > for that as well. I just wanted to mention that if we solve this problem as described above BASE will behave differently on Postgres and MySQL. On MySQL all reporters will be case-insensitive and "demoblank"/"demoBLANK" will be the same reporter. On Postgres they will be two different reporters. > Time to balance the negative with some positive... BASE2 is so much nicer to > work with than BASE1, keep up the great work guys!! Thanks! /Nicklas ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ The BASE general discussion mailing list basedb-users@lists.sourceforge.net unsubscribe: send a mail with subject "unsubscribe" to [EMAIL PROTECTED]
