Good improvement, you also found the crash bug i was referring to last night!

One concern I have is the whole concept of allowing different object types share the same name. If Kexi allows this, im not very comfortable with it. How could a query be based on a query that shares a name with a table ... a class of problems would be wiped out if we didnt allow duplicate object names, like all other db engines I assume.

thoughts?

This was something i was thinking about as I stripped out the checking for part/object type in my simple fix .... i thought it just couldnt be a problem as we shouldnt have duplicate names :)

In D765#14548, @piggz wrote:

Good improvement, you also found the crash bug i was referring to last night!

One concern I have is the whole concept of allowing different object types share the same name. If Kexi allows this, im not very comfortable with it. How could a query be based on a query that shares a name with a table ... a class of problems would be wiped out if we didnt allow duplicate object names, like all other db engines I assume.

Very good point. Unique identification include class everywhere as you've seen even in this patch. But the only known thing I missed is the grammar of SQL. Without a special syntax like QUERY<name> or so there's no solution.

I checked MSA today and you're right, there cannot be the same table and query name:

However there can be the same name used for:

• table and {anything but query}
• query and {anything but table}

Example for table and form:

Summing up

• How about filing a wish "Do not allow tables and queries having the same name"?;
  • this is about disallowing to do so in the Kexi GUI, in KDb itself
  • I am unsure if we should checking for such cases on loading of existing Kexi -- what should we do then?
    • Display annoying warning?
    • Loading only tables?
    • Not loading anything?
    • No.. I'd leave existing .kexi projects as they are and just let SQL statements fail when problematic names are used.
• I would update the above patch to follow the rule of MSA for names of tables and queries. But isn't the logic we have in the patch good for backward compatibility? It lets us to pick query A if table A also exists. So I would leave this behaviour of this patch.

Thoughts? Anything I missed?

One more thing.

I think it's good if we have "source-class" attribute in addition to "source" because this makes data source assignment deterministic. Without this behaviour if someone removes table A and adds a new query A, reports with source == "A" would still work. That's not totally expected.