Latest SM issue with SQLOrigin

Data Abstract
1

Does the schema modeller remove from the DFM the lines with SQLOrigin in them now? I made a small change to something in a service and when something unrelated failed I discovered lots of these lines gone and the failure seemed to be because:

  1. It was using a manual SQL (joining a couple of tables)
  2. In the DFM, the definition for the table being used had DatasetField, TableField and SQLOrigin all set to something. The TableField oddly was not actually to do with the specific tables in the join but was from another table. Not sure how that got there, but looking in my git, it’s been like that for a while.
  3. It seems when SQLOrigin is present and correct, it works but when it wasn’t it looked for the unavailable TableField and that caused a failure.

I have too many to go and check if there are any other similar fields setup similarly (I have already found another couple) so just thought I’d ask if this is an expected thing for these to be removed?

2

Hi,

What build of DA are you using?

we have

   property SQLOrigin: string read GetSQLOrigin write SetSQLOrigin stored StoreSQLOrigin;
...
function TDAColumnMapping.GetSQLOrigin: string;
begin
  if (fSQLOrigin = '') then Result := TableField else Result := fSQLOrigin
end;

function TDAColumnMapping.StoreSQLOrigin: Boolean;
begin
  Result := (fSQLOrigin <> fTableField) and (Trim(fSQLOrigin) <> '');
end;

so if it is the same as TableField, it isn’t stored.

if SQLOrigin is differ from TableField and it is removed from .daSchema - this is a bug.

edit: seems DASM saved schema correctly:

Untitled
Untitled2087×1339 112 KB

3

Then it’s a bug, they are different. I’m using .1585. I can try with .1587 if it helps.

4

Hi,

can you post simple testcase to support@, pls?

5

I’ll see if I can build a test case.

6

What happens if you edit the DFM manually so TableField for one of them is something random, but SQLOrigin is the same as the DataTableField, which is the situation I have, like so :

          item
            DatasetField = 'sum_open_value'
            TableField = 'HouseIndex'
            SQLOrigin = 'sum_open_value'
          end

Then make a change and save it.
Note I can replace the HouseIndex with sum_open_value and it then works (the SQLOrigin is fine to be removed now)

7

Hi,

works as expected:

animation2

8

OK, I have done this, using the DAServer project.
Edited the DFM to change the client discount field to match how my project is:

Screenshot 2024-04-09 at 16.31.46
Screenshot 2024-04-09 at 16.31.46996×758 31 KB
.

Looking in SM:

Screenshot 2024-04-09 at 16.29.37
Screenshot 2024-04-09 at 16.29.371628×1370 339 KB

Now close it SM without changing something, and it works. Make SM think something’s changed to force the save, and it gets removed:

Screenshot 2024-04-09 at 16.30.12
Screenshot 2024-04-09 at 16.30.12996×758 16.8 KB

(edited as posted wrong image!)

9

Curious. I’ll investigate more. There’s clearly more to it.

10

Hi,

in my video I’ve changed statement name so Schema Modeller has to re-save .daSchema …

edit: I can reproduce original issue if schema uses old v3 (xml) format.
investigate this case …

11

Yes, you also did things differently to me, but now I’ve just gone to repeat it (my way), and it did save as expected, i.e. it left the SQLOrigin in place. I’ll keep looking to find how to make it repeatable.

Incidentally, I don’t think I’ve ever used the structure/obj inspector in Delphi to modify DA things, I’ve always used the SM.

12

Ah, interesting, can I find this some place? Mine is certainly old (started this one with DA version 1 !) but I do update things as I need to.

13

Hi,

.1587 should solve your original issue.
since this version, DAD saves .daSchema in json (v4) format when it is passed to Schema Modeller.

in .1585 - xml (v3) format was used and it causes that issue

14

Thanks Eugene, that one does seem to work correctly. I only hadn’t tried this one as we are getting close to a software release and I don’t like to change things like this until after that!

15

Logged as bugs://D19457.

16

bugs://D19457 was closed as fixed.