Get Design-time Data problems

Data Abstract
1

Having some weird problems with the Get Design-time Data option on TDAMemDataTables.

Some of them work fine. A couple are producing a “Dataset: Field ‘Id’ not found” despite the fields all being correct and even after repopulating them from the schema.

Some others are locking the Delphi IDE up completely. It goes totally unresponsive and has to be killed via Task Manager.

Any ideas on what could be causing this?

2

it opens datatable via DataAdapter and performs login if it is required:

        if dt.LogicalName = '' then
          raise Exception.Create('LogicalName must be set.');
        DAValidateProperty(not dt.RemoteFetchEnabled, dt.Name, '.RemoteFetchEnabled must be True');
        if dt.RemoteFetchEnabled then
          if assigned(dt.RemoteDataAdapter) then begin
            (dt.RemoteDataAdapter as TDABaseDataAdapter).CheckProperties();
            if dt.RemoteDataAdapter is TDARemoteDataAdapter then begin
              fRemoteService := (dt.RemoteDataAdapter as TDARemoteDataAdapter).RemoteService;
              lSaved := fRemoteService.Channel.OnLoginNeeded;
              fRemoteService.Channel.OnLoginNeeded := OnLoginNeeded;
              try
                dt.Open();
              finally
                fRemoteService.Channel.OnLoginNeeded := lSaved;
              end;
            end
            else begin
              dt.Open();
            end;
          end;
        Designer.Modified;
3

Hmm, we already checked the database connection was all ok so there shouldn’t be an issue. Can’t work out what’s going on here.

4

what dataadapter is used? RDA or LDA ?

5

At design-time it’s hooked up via a LDA (at runtime it can use either depending on whether the table is being used server or client-side)

6

Looking at the code you quoted, in the case where it’s using an LDA, it just opens the table. I just tried merely setting the table’s Active property to True and sure enough, it’s frozen the IDE again. This is bizarre.

7

can you create a simple testcase that reproduces this behavior, pls?
it may depend on used database driver.

8

I doubt it to be honest - it’s been working fine until today and now only on certain tables (although I can’t see any fundamental difference in the way these are configured). I’ll give it a go and see if I can.

9

Just tried it again and got this:

“Access violation at address 392478D5 in module ‘DataAbstract_Server_IDE_D20.bpl’. Read of address 00000000”

There’s something very weird going on here.

10

weird. I can’t reproduce it with simple testcase.
what DAD version you are using?

11

Sorry, not sure what you mean by DAD (It’s early here :p)

12

I’m trying to detect what version of DataAbstract for Delphi you are using. we have released 6 DA8 versions since last summer…

13

Ah sorry, I’m on 8.0.83.1137.

I know there have been a few versions since then but I hit a bug when I upgraded to one of them a while ago (which I reported and was fixed) and I’ve not got round to upgrading again since.

14

can you specify host application as bds.exe for DataAbstract_Server_IDE_D20.dpk and launch it in debug mode and receive call-stack, pls?

15

You mean load the DataAbstract_Server_IDE_D20.dpk in Delphi, set the host app and then run it so it spawns another copy of the IDE, then load my project in that instance and try setting the table to active?

I’ve tried this (got some file in use errors when the second IDE instance started) but I can’t reproduce that error right now, it’s just back to seizing up.

16

yes. First instance of IDE should catch AV in second instance and provide some useful debug info.

17

Ok I’ll play with it a little and see if I can make it happen.

Also I could try tracing the code from the moment I set the table active and see if I can find out where it hangs up - whereabouts in the RO source would best set a breakpoint to trap this?

18

you can set breakpoint into Data Abstract for Delphi\Source\IDE\uDADataAbstractEditors.pas:

procedure TDADataTableEditor.ExecuteVerb(Index: Integer);
..
    11:{$IFDEF DELPHI10UP}{$REGION 'Get Design-Time Data'}{$ENDIF}
      begin

            if assigned(dt.RemoteDataAdapter) then begin
..
            end
            else begin
              dt.Open(); //<<<< here
            end;
19

Aha, seems to be hanging at TDADataTable.DoOpen on the call to DoOpen_ValidateLookupSource.

This kind of makes sense as the table in question has an incomplete lookup field as the source for this lookup is in another data module which is created at runtime and the lookup field is updated accordingly, so there’s no source at design time.

20

If I set the LookupSource properties for all these lookups to the relevant data source in the other data module, and have that data module open in the IDE then it seems to start working, although it does take a while to complete. The code then changes these properties to point to the actual instance of the other data module created at runtime.

I’m guessing there’s no other way of doing this. We have several such lookup tables which are very common (finding user names from IDs etc) and used by all manner of data tables. We don’t want to create duplicates of these lookup tables in every data module in which they’re required as, if the database structure changes at all, we’d then have to find every one of these lookup tables to update them from the schema. I feel it’s better to have such commonly used lookups only once in a central data module which is instantiated as required by the other data modules and then hooked up to the relevant lookup fields at runtime.