Alright, we getting closer. The insert statements would simply have helped me to produce a copy of your exact DB on my side - but since the DB file and query seems to produce output you expect, there is not much use in that. The problem boils down to, if I understand your post correct, that while the query works, an alias in the query is somehow not propagated to your code, at least outside some scope. I have to say that that is something that is completely up to your code or perhaps the wrapper that you use. In SQLite there is no scope "outside" the query, and anything that was transferred from SQLite to the application code was done so "within" the query call. I estimate (but do not know for sure) that your PERL wrapper somehow "forgets" about the returned names (i.e. column Aliases) once the query completed, and even though you are calling it in a loop, that loop simply walks PERL memory, and the SQLite API has long since been put to rest (presumably). ## Why do I estimate this? In normal API usage, we would prepare the Query, set the parameters (if any), then keep calling sqlite3_step() and reading the bound values from the statement until it returns something other than SQLITE_ROW. During that time, at any point, you can get the column name from the prepared statement (See: [sqlite.org/c3ref/column_name](https://sqlite.org/c3ref/column_name.html)) which, if you read it, you would notice is *exactly* what you expected, namely the alias specified in the query. You can therefore see that it is very hard for us to guess at WHY your PERL code or its wrapper (that does all this preparing and stepping for you) is somehow not knowing this information. All I can tell you is that on SQLite's side that information is definitely available and works exactly like how you expected. Our knowledge and jurisdiction ends right at those API functions. Once the higher level application code has the value, we have no clue what/how/why stuff happens to it. Maybe a PERL person or forum would be more help to you.