PR# 15470 EiffelStore's hashtable key comparison fails due to '~' operator

As stated in the Release notes to release 6.4.7.6313, using the '~' operator in EiffelBase breaks the hashtable mechanism used in EiffelStore.

The mapping mechanism (e.g. feature `set_map_name' in class STRING_HDL used by DB_SELECTION) for parametrizing SQL queries uses a hashtable for holding key-value pairs. Upon retrieving these mapped values when building the SQL-query (feature `replacement_string' in class SQL_SCAN), the default key-comparison using `same_keys' fails because it compares a STRING to a DATABASE_SELECTION[ODBC] (as i use ODBC) object. Mappings do not get inserted properly, and are replaced in the query by "NULL". 
Thus, queries like
  "SELECT * FROM :table_name"
get changed to
  "SELECT * FROM NULL"


I provided a minimal invasive patch for this bug for your consideration. It changes the call for retrieving the hashtable's item by creating a new, proper STRING instead of using the subclass DATABASE_SELECTION[ODBC].

1. Setup a database and enter some values
2. Connect using EiffelStore
3. Retrieve the previously entered values by using the mapping-mechanism, e.g. 
	l_selection.set_map_name (an_id, "id_map")
	create l_query.make_from_string ("SELECT * FROM `test_table` WHERE id=:id_map")
	l_selection.query (l_query)
4. inspect the retrieved data


Note: Attached (in the "src" subfolder) is a small program presenting the bug, follow the instructions in the README to setup the application.

Fixed in rev#77622.

Thanks for providing the patch. Unfortunately, I'm not sure it is sufficient because you do not have a guarantee that items inserted in the HASH_TABLE are always of type STRING. I'm proposing a different patch which will simply use `same_string' rather than `~' for comparing STRING objects all the time.

The benefit is that is should as efficient as the original solution (no need to create a temporary object for lookup.

The next 6.4 release will have the patch included. Let me know if it also works for you.

Attachments for problem report #15470