mORMot Open Source

Thanks for pointing me in the right direction, the culprit was
indeed here, the missing index name with Delphi did not give any problems.
But with Lazarus, apparently the multi-index was not being created.

However, the following code only works fast once, the 2nd time,
it acts as if there is no index, until I change again the name of the index.
Am I missing something, perhaps having been using CreateSQLMultiIndex  wrongly all along...?

  lang :=   TRestClientDB(GG_globalClient).Server.Server.CreateSQLMultiIndex(
             TOrmTbl1, Ar_IndexesB,True,'IndexName1'); // quick only if IndexName change for each run

P.S.
Tried using the memory manager mormot.core.fpcx64mm with FPC 3.3.1, it compiled,
but at run time got a mysterious segmentation fault.

Hi,
am probably missing something, but under 'core', found an update for file mormot.core.variants.pas
but unfortunately could not find one for file  mormot.core.rtti.pas where the error appeared,
so am still getting the same error..

Thanks a lot, again moved one step further, now the error is in File mormot.core.rtti.pas in line 5590:

{$ifndef HASNOSTATICRTTI}
      if (not FirstSearchByName) and
         (Info = TypeInfo(TGuid)) then // ERROR here, line 5590: E2134 Type 'TGUID' has no type info

Agree that Lazarus' s incremental compiling is neat!

Work with an external drive, which currently is no longer an SSD, should probably get one, although writing
to an SSD is still slow compared to its blazing read speed...

Thanks for this hint, ab. Made sure that the correct synopse.inc
was being used (renamed the file to synopsenew.inc, changing all inc.references in the *.pas files accordingly).

However, compilation still stops at the file SynZip.pas
due to the following declaration.

Var
    PDataStart: ZipPtrUint;

Am definitely using D2009, (checked that constant CompilerVersion does return 20)
so this is really puzzling...seems as if the D2009 directives are having no effect..?

Hello,

Tried the above code in a new, separate application and it works just OK.
However, when used together with the original application with the native Oracle
driver unit SynDBOracle, it just won't write a file when called
by UpdateToFile.
It does report a filesize however, using
FileSizeOnDisk,
which is suspiciously large, over 40GB.

Could this be somekind of memory interference...

Much obliged for your comments. In the meantime,
will try  using TSynBigTable instead.

Hello,

Thanks a lot for both your help.

Using:

aDynArray(TypeInfo(TStudents),MyStudents).LoadFromStream(MStream_)
would not compile,  perhaps the error is elsewhere..

Anyhow, got rid of the memory streams and using the following
code no longer produces an access error,
but now fails to find the given student (which should be in the file).

Still need to try this with a new framework...

Var
     Raw_:        RawByteString;
indx_,StudentsCount:Integer;

BEGIN
Raw_  := BinToBase64(StringFromFile(GG_STUD_DIR +  GG_S_
                    +  'Stud_Info' + GG_TXT));
StudentsCount := 0;
aDynArray.Init(TypeInfo(TStudents),MyStudents, nil, nil, nil, @StudentsCount);

aDynArray.Capacity := 120000; 
DynArray(TypeInfo(TStudents),MyStudents).LoadFrom(Pointer(Raw_));

 aStudent.sStudentId := '296380'; // student actually is in file...

 indx_ := aDynArray.FindHashed(aStudent); // indx_ returns -1
END;

Just to add to the previous post, downloaded the latest nightly build
and now BatchSend works fine the first time when adding  a set of records.

If however, the same set of records are added again, the
application returns error code 500, 'internal server error'.
Could it be that the new Mormot
is now  complaining of key violations which went unnoticed before...

Am using the following though for addind records...:

GG_globalClient.BatchAdd(mytbl, True);

Hello,

Many thanks for all your help, finally went back and
changing NativeUInt to UInt did solve this mysterious problem!

Now, however, when trying to compile a D2009 application
containing the BatchSend command (as below) that used
to compile fine with a very old Mormot (from Jan '14)
gives the following error when compiling it with a new Mormot from Jan '17:

' There is no overloaded version of batchsend that can be called with
these arguments..'

Would be very grateful for any hints, am not aware of changes in BatchSend...

Cheers,
Sami

Var
AllResults: TIntegerDynArray;

 GG_globalClient.BatchSend(AllResults);

Yes, will do that, thanks. Just wanted to get 'the big picture' right.

OK, will try that, thanks!

Many thanks! Was looking for the error in the wrong place, thinking that
some additional binding was required.

Thanks a lot! Felt that something was missing but could not figure out what.

The client can now run successfully w/o having
to run as 'admin'  (am using localhost on a single PC)

However, when it doesn't run as admin, seems to be slower...

Thanks for this info, now compiled latest unstable version with no problem.

Can now finally add data to the server tables, (not using batch yet)
however, when stepping on the statement:

GG_globalClient.TransactionBegin(TSQLMyTable2)

still get the error Exception class EOSError' with message 'System Error. Code 12152
which apparently means the following:

HTTP Status 12152 The server has been taken down momentarily for database or server maintenance, or there has been a network error. This status will generally come up when attempting to upload.

Wonder if you have any ideas on this?

Thanks for your pointers, in fact, it turns out that
only one of the tables works with regular Add
(both have a similar structure though)
and none of them will work with
TransactionBegin:

GG_globalClient.TransactionBegin(TSQLTable1);

causes a mysterious 'Exception class EOSError'
with message 'System Error. Code 12152,
apparently generated from InternalGetInfo32 in
TWinHttpAPI.Request in the unit SynCrtSock

The server code is very simple:

Try
aProps := TSQLDBSQLite3ConnectionProperties.Create(ChangeFileExt(paramstr(0),'.db'),'','','');
  VirtualTableExternalRegisterAll(aModel,aProps);
  Try
    aModel := get_model_HEVDB; // tbls defined in unit HEVDB

   DB :=   TSQLRestServerDB.Create(aModel,'Hev.DB3',
                    CHECK_USERS); 
        DB.CreateMissingTables;
      Try
      aServer := TSQLHttpServer.Create('888',[DB]);

          Write('Press [Enter] to shut down server.');
     finally
        aServer.Free;
      end;
    finally
      aModel.Free;
    end;
  finally
    aProps.Free;
  

To step down code in the server would require attaching some event handler to
the server,  I guess?

Yes, am actually using TSQLRestClientURINamedPipe to
connect on the client side, although the server and client are still
in the same PC.

The client can now successfully retrieve data from a table defined on
the server, My mistake sorry, no additional definitions are
needed on the client side, thanks for pointing this out.

I assume when the server is located physically on another PC,
this method should still operate rather fast?

Thanks a lot,
Sami

Thanks so much for pointing this out,
somehow got confused in the order of parameters :-).

OK, thanks a lot for your kind help.
Can figure out a manual workaround then..

Thanks for your tip,
I already tried the following to create a multifield index ( 6 fields).

It seems to have no effect,
as the application happily keep inserting duplicates
into the same table without giving any error..

  TSQLRestClientDB(globalClient).Server.CreateMissingTables(0);


  TSQLRestClientDB(globalClient).Server.CreateSQLMultiIndex(TSQLmyTable,
    
  G_CRSTBL_INDEXES_Ar,True);

G_CRSTBL_INDEXES_Ar contains
6 field names starting from index 0.

I'd like to have control of the code when there
is a key violation  to update
the existing record if necessary.

Know that there is a method such as

TSynTableFieldProperties.Validate()
but couldn't find an example on how to use it.

Could you give me one more hint, please?
Thanks!