You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I do create COLUMN with the COLLATE NOCASE. Sqlite browser does not parse COLLATE NOCASE
statement correctly.
e.g:
CREATE TABLE MyTable (ID INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE,Filter TEXT COLLATE NOCASE)
Can you maybe try the latest nightly build (see here: https://github.com/sqlitebrowser/sqlitebrowser#windows) because we've made some changes in the meantime and at least for me your table statement gets parsed correctly 😃
Was just going to raise a ticket when I saw this was already here.
Using the latest nightly build (13 Jun) and this works 40% successfully (using Windows 10 64bit)
Maybe I broke it, but I 'cheated' by editing a table and changing the field from 'text' to 'text collate nocase'. DB4S kindof accepted it...
But its not in the dropdown
...and the 'Modify Tab;e' GUI doesn't see it.
It does physically work though - the field is now nocasing, so 'fred' is found with a field containing 'FRED'. Adding a field doesn't break this, but MOVING a field does.
So it works, but only just...
I added a table via SQL, and the same results occurred. Physically worked, appeared in the schema line but not the dropdown, and not in the 'Modify Table' GUI. Adding a field didn't break it, but moving a field did.
As long as you're just inserting, updating, or deleting records there is no need to be concerned at all. This works just fine. You only get in trouble when editing the table using our Edit Table dialog. In this case the collation gets dropped. That issue is related to #741. I'll try to fix that, too, so there's no need to worry about collations here anymore 😃
This should be working in the next nightly build. Do you have the time to check if it's fixing your problems, @mtissington, @slidertom and @chrisjlocke? You still can't edit collations in the Edit Table dialog but at least they shouldn't get lost when editing the table.
I can confirm that moving columns "COLLATE NOCASE" appears to work, no schema info is lost. Table browser still looks scary with dialog warning though... What's the worst that can happen?
With tomorrow's nightly build the warning should be gone for COLLATE NOCASE as well as BINARY and RTRIM. It's still going to be shown for other collations (and actually makes some sense for these, even though the wording could be tweaked a little).
@wezzix Want to download tomorrow's nightly build and check if the warning is gone for your database? I think we can finally close this issue then 😄
Activity
justinclift commentedon Sep 9, 2015
Oh, that's not good. Which version of DB4S are you using, and which OS are you on?
slidertom commentedon Sep 9, 2015
DB4S: Version: 3.7.0
OS: Windows 7 64 bit
MKleusberg commentedon Sep 11, 2015
Can you maybe try the latest nightly build (see here: https://github.com/sqlitebrowser/sqlitebrowser#windows) because we've made some changes in the meantime and at least for me your table statement gets parsed correctly 😃
glawrence commentedon Dec 7, 2015
@slidertom did you get a chance to test this please?
chrisjlocke commentedon Jun 14, 2016
Was just going to raise a ticket when I saw this was already here.
Using the latest nightly build (13 Jun) and this works 40% successfully (using Windows 10 64bit)
Maybe I broke it, but I 'cheated' by editing a table and changing the field from 'text' to 'text collate nocase'. DB4S kindof accepted it...
But its not in the dropdown
...and the 'Modify Tab;e' GUI doesn't see it.
It does physically work though - the field is now nocasing, so 'fred' is found with a field containing 'FRED'. Adding a field doesn't break this, but MOVING a field does.
So it works, but only just...
I added a table via SQL, and the same results occurred. Physically worked, appeared in the schema line but not the dropdown, and not in the 'Modify Table' GUI. Adding a field didn't break it, but moving a field did.
mtissington commentedon Feb 14, 2017
I am still getting this error on the latest nightly build.
Do I need to be concerned about this?
Can you fix it?
MKleusberg commentedon Feb 17, 2017
As long as you're just inserting, updating, or deleting records there is no need to be concerned at all. This works just fine. You only get in trouble when editing the table using our Edit Table dialog. In this case the collation gets dropped. That issue is related to #741. I'll try to fix that, too, so there's no need to worry about collations here anymore 😃
grammar: Parse collations in column definitions
MKleusberg commentedon Feb 17, 2017
This should be working in the next nightly build. Do you have the time to check if it's fixing your problems, @mtissington, @slidertom and @chrisjlocke? You still can't edit collations in the Edit Table dialog but at least they shouldn't get lost when editing the table.
wezzix commentedon Jul 11, 2017
I can confirm that moving columns "COLLATE NOCASE" appears to work, no schema info is lost. Table browser still looks scary with dialog warning though... What's the worst that can happen?
chrisjlocke commentedon Jul 11, 2017
MKleusberg commentedon Oct 19, 2017
With tomorrow's nightly build the warning should be gone for COLLATE NOCASE as well as BINARY and RTRIM. It's still going to be shown for other collations (and actually makes some sense for these, even though the wording could be tweaked a little).
@wezzix Want to download tomorrow's nightly build and check if the warning is gone for your database? I think we can finally close this issue then 😄
justinclift commentedon Dec 4, 2017
Closing this as it was fixed a while ago, and multiple people have confirmed
COLLATE NOCASEnow works properly. 😄