Re: [sqlite] View workarounds

On 2016/05/25 5:42 PM, Balaji Ramanathan wrote: Thanks again, Ryan. The options right now come down to either expanding the view with all the raw columns so that I can filter and sort directly using a select * from view. Or I can use the view for unfiltered, unsorted look at my data, and use

Re: [sqlite] View workarounds

On 25 May 2016, at 4:42pm, Balaji Ramanathan wrote: > I vote for more extensive support of hidden columns in tables, views, etc. > Is there some site for submitting enhancement requests for SQLite? It's here. You just did it. Don't hold your breath. Simon.

Re: [sqlite] View workarounds

Thanks again, Ryan. The options right now come down to either expanding the view with all the raw columns so that I can filter and sort directly using a select * from view. Or I can use the view for unfiltered, unsorted look at my data, and use the query of the view to do filtering and sorting.

Re: [sqlite] View workarounds

On 2016/05/24 2:17 AM, Balaji Ramanathan wrote: Thank you for continuing with this thread, Ryan. I don't have nuclear launch codes in my database, but it is over 4MB in size. But the data in it is not that important. Let me post the view I am interested in: select Trip.TripID as 'Trip

[sqlite] View workarounds

On 2016/05/23 7:52 PM, Balaji Ramanathan wrote: > Thank you very much for all your comments. > > I thought about including all the columns in my view and then selecting > just what I need, but that is almost as painful as repeating the view's > query in adding the filters I want. Modifying both

[sqlite] View workarounds

Thank you for continuing with this thread, Ryan. I don't have nuclear launch codes in my database, but it is over 4MB in size. But the data in it is not that important. Let me post the view I am interested in: select Trip.TripID as 'Trip Number', Mode.Mode as 'Mode', TripOD.TripOD as

[sqlite] View workarounds

On Mon, May 23, 2016 at 4:49 PM, Steve Schow wrote: > My suggestion is add the extra columns you need to the view, then when you > make a query against that view, only specify the more limited set of output > columns you want in the final output > SQLite almost supports what's needed, but only

[sqlite] View workarounds

On 2016/05/23 3:02 PM, Balaji Ramanathan wrote: > Hi, > > I have created some views in my database by joining multiple tables to pull > out specific columns from these tables without having to remember the exact > SQL and joins (easy repeatability). But it looks like I have misunderstood > how

[sqlite] View workarounds

As long as you don't try to modify data, a view just behaves like a base table. So, like in base tables, you can't extract, filter, sort, group by, etc. based on non-existing columns. SQLite views are read-only, but modifying data through a view can be done with "instead of" triggers. J-L

[sqlite] View workarounds

Thank you very much for all your comments. I thought about including all the columns in my view and then selecting just what I need, but that is almost as painful as repeating the view's query in adding the filters I want. Modifying both the select clause and the WHERE clause of the query is

[sqlite] View workarounds

My suggestion is add the extra columns you need to the view, then when you make a query against that view, only specify the more limited set of output columns you want in the final output As others have said already, don?t think of a view as a stored query. Think of it as multiple joined

[sqlite] View workarounds

Hi, I have created some views in my database by joining multiple tables to pull out specific columns from these tables without having to remember the exact SQL and joins (easy repeatability). But it looks like I have misunderstood how views work and have run into some limitations when using these