Virtual and persistent columns are a feature of MariaDB 5.2+, and HeidiSQL's table editor now fully supports them. Just update your HeidiSQL to the latest build to see this in action.
Also, if you are on a MariaDB server, a brown seal icon in the tree and in the status bar now indicates the right server vendor:
Virtual columns in MariaDB
I am trying to create and expression which will calculate the difference between two columns in a virtual field.
Similar to your table structure above, it would seem the expression for column "c" would be b-a (assuming all columns a, b and c are integers, for example - with appropriate sizes - i.e. c is big enough to hold b-a).
I keep getting the error "1907: this is not yet supported for computed columns"
I am running MariaDB v. 5.5.35
Any help would be appreciated!
[Today I am wearing a HeidiSQL t-shirt I received at MySQL Conference (approximately 2009 or 2010) in the hopes I would be inspired to have fewer coding problems. Look where it got me! ]
Similar to your table structure above, it would seem the expression for column "c" would be b-a (assuming all columns a, b and c are integers, for example - with appropriate sizes - i.e. c is big enough to hold b-a).
I keep getting the error "1907: this is not yet supported for computed columns"
I am running MariaDB v. 5.5.35
Any help would be appreciated!
[Today I am wearing a HeidiSQL t-shirt I received at MySQL Conference (approximately 2009 or 2010) in the hopes I would be inspired to have fewer coding problems. Look where it got me! ]
Guess you have the shirt from the jHeidi developer Bill, who was at the conference at that time. See here for some photos: https://www.facebook.com/media/set/?set=a.391851224278756.1073741825.254708651326348&type=1
I found a hint saying that virtual columns cannot be modified: https://lists.launchpad.net/maria-docs/msg00281.html
I found a hint saying that virtual columns cannot be modified: https://lists.launchpad.net/maria-docs/msg00281.html
Hi Ansgar:
D'Oh! I saw the same "no alter" rule in the main MariaDB KnowledgeBase for virtual columns
Unfortunately, I somehow understood that to mean "no alter once the virtual column is established" [I was trying to modify a "regular" column (which, further, had never contained any data) into a virtual one which in my opinion meant I was not modifying the virtual column . . . Grrrrr. I hate when I fail to look at an instruction from more than one angle.]
OK, I dropped my original column, made a new one as virtual AT THE TIME OF COLUMN CREATION . . . and it works!
Thanks!
Yep, this is the shirt I had on today.
HeidiSQL already showed great promise at that 2009 conference, but I was already a licensee of SQLYog and used that for most of my MySQL db work.
Just 5 years later (I started using HeidiSQL fairly seriously about 8 months ago), your tool is better than ANY competitor's, particularly in terms of usability and intuitiveness. The only reason I still keep SQLYog around is for automation and synchronisation (data, schema, etc). The automation and synchronization can also work together in SQLYog, a killer feature! I mentioned it previously here.
D'Oh! I saw the same "no alter" rule in the main MariaDB KnowledgeBase for virtual columns
Unfortunately, I somehow understood that to mean "no alter once the virtual column is established" [I was trying to modify a "regular" column (which, further, had never contained any data) into a virtual one which in my opinion meant I was not modifying the virtual column . . . Grrrrr. I hate when I fail to look at an instruction from more than one angle.]
OK, I dropped my original column, made a new one as virtual AT THE TIME OF COLUMN CREATION . . . and it works!
Thanks!
Yep, this is the shirt I had on today.
HeidiSQL already showed great promise at that 2009 conference, but I was already a licensee of SQLYog and used that for most of my MySQL db work.
Just 5 years later (I started using HeidiSQL fairly seriously about 8 months ago), your tool is better than ANY competitor's, particularly in terms of usability and intuitiveness. The only reason I still keep SQLYog around is for automation and synchronisation (data, schema, etc). The automation and synchronization can also work together in SQLYog, a killer feature! I mentioned it previously here.
Please login to leave a reply, or register at first.