Re: EDS:: NO_TABLE, db_table_list()
- Posted by K_D_R Feb 12, 2012
- 1356 views
The NO_TABLE error code is returned only by those functions that can take a table name as a parameter and the supplied table name is not known in the current database. ... The db_table_list() function does not accept a table name as a parameter so it does not return NO_TABLE.
I somehow miss the above information in the documentation. Given the current state of the documentation search facilities, it could be there and easily missed. What I do see is this:
8.28.3.4 NO_TABLE include std/eds.e namespace eds public enum NO_TABLE no table was found.
No table was found. Certainly, no table was found by db_table_list() when the current db had no tables. Shouldn't that statement be replaced by a more accurate description, such as Derek has provided above?:
The NO_TABLE value should more accurately be described as the specifically requested table was not found.
Thank you.
The documentation currently makes no reference to an empty sequence.
That is true. However I didn't think it would have to as an empty sequence is a list of all the tables in a database that contains no tables. I thought it was self evident as in ... 2 entries means there are 2 tables, 1 entry means that there is one table and zero entries therefore naturally means that there are no tables.
However, for Jiri's sake, I'll add this to the documentation.
"A list of all the tables in a database that contains no tables", eh. You may as well rename the language , "Obfuscoria".
This is what should be self-evident to you. This whole imbroglio was brought about because the documentation had the error code NO_TABLE listed with the sole description "No table was found", and absolutely no other reference as to how it should be used. Therefore, it seemed self evident to me that when after a call to db_table_list() "no table was found" in the database, then NO_TABLE was an appropriately descriptive error code for the circumstance at hand.
So for Jiri's sake, I thank you again, in advance, for improving the documentation.
Regards, Kenneth Rhodes