mORMot Open Source

I think your code is logical and OK.

Try DateTimeToSQL instead.

A related discussion is here: https://synopse.info/forum/viewtopic.php?id=4909

@pvn0,

That's a bunch of helpful info and links you have provided, that gives me the direction for a possible solution for the issue! Thank you very much!

@MC,

I suggest you to create a new pull request at https://github.com/synopse/mORMot/pulls so that ab can review it.

Good idea! May be use memory mapped file? I think ab will accept your changes if you don't break any compiler supported by mORMot

PS:
My currently planned solution is to define a child class from TRawUTF8ListHashed (which are stored as JSON text in the db according to the document, since it derives from TRawUTF8List) for storing int64 values, for example:

type 
  TInt64ListHashed = class(TRawUTF8ListHashed)
  public
    Add(aValue: Int64): PtrInt; overload;
    IndexOf(aValue: Int64): PtrInt; overload;
end;

and use this type as the field type.

Sounds very cool!

Hello ab, out of curiosity, when sqlite is configured to allow multi connections, does it also use a lock to coordinate the multiple access, or does it have a better approach than locking?

Hello mpv, interesting, I assume you mean (https://www.freepascal.org/docs-html/rt … pause.html)

Do you know similar things exist for Delphi for Windows

The following works perfectly for SQLite for me, but since mORMot persists datetime fields as ISO8601 I think it most probably also works with MS SQL.

function GetDateTimeRangeFilteringSqlClause(const aFieldName: String; const aStartTime, aEndTime:
    TDateTime): String;
begin
  Result := Result + FormatUTF8('(%>="%" AND %<="%")',
    [aFieldName, DateToIso8601(aStartTime, True), aFieldName, DateTimeToIso8601(aEndTime, True)]);
end;

checked out and starred, thank you!

Ah yes! Discovered log entries such as "SetThreadName 000026BC=TSQLHttpServer 80/root THttpApiServer". Thanks.

Thanks for sharing, would be great if put it in a github repository

@alpinistbg,
I agree with you about that 'one should resort to first trying to find the source of the errors instead of just checking for if Self := nil'. ab might has his opinion based on the new replies here... In a perfect world (which is non-existence) I also wish ab stop using the 'with' keyword, but that's another question

Also need to consider - maybe there is another case where those 'if self = nil' guard clauses have reasons to stay - mORMot is a framework, and the clients (the code that the users of mORMot write) might be some mess multi-thread code and cause 'self = nil' to happen?

Why do you think so? It's not a programming error but a very good programming technique called "Guard Clause" which makes the program reliable and clear to read.

ref1: https://en.wikipedia.org/wiki/Guard_(computer_science)
ref2: https://medium.com/@scadge/if-statement … 219a1a981a

A article related to the fact that self might be nil: http://blog.marcocantu.com/blog/when_self_is_nil.html
Also notice one of the comments:
"I've actually seen self = nil a few times, especially
in multi-threaded code.  I have a couple methods that
start with ". -- Jim McKeeth

I heard about valgrind  for the first time, what an amazing tool and what an amazing you've done!

I haven't dig into the source of TransactionBegin, but if what you described is true, it definitely has a room to improve.

@alpinistbg,
I have complete going through all your 3 posts related to these issues related to the client-side batch operations.

The issue
===
I have a POS program which completely relies on the client-side, UOW batch operations, and I had an issue that's almost identical to yours - it happened during a multi-db to central-db syncing process which is implemented using batch process.

When the batch update failed, I found mystery error messages in the log file: "Error SQLITE_ERROR (1) [Step] using 3.15.1 - cannot rollback - no transaction is active, extended_errcode=1", followed by a  "TransactionBegin timeout" error .

From the error message I have no clue about what actually went wrong, until many months later,  it turned out to be a primary key violation (you know, syncing from many branch db to a central db).

The cause of the error revealed when I have the actual data from the client and running the server-side software in the IDE.

I don't know why neither the mORMot engine log nor the caught exceptions didn't tell me the actual database error messages, otherwise I should have identified the error much much earlier.

But after that, the software which's powered by mORMot has been running for years without issues.

My thoughts
===
- It's a must for ether the server-side log or the BatchSend to tell the actually database system error message, I prefer BatchSend should return the actual database error code and message.

- As @alpinistbg has found out the 2-second timeout for starting a transaction should not be hard-coded - at least it should be customized via a property.

- To implement a retry-able client-side batch update, maybe we can do this:
  a, before calling BatchSend, make a copy a the TSQLRestBatch instance.
  b, if BatchSend failed, make sure the db is rolled back. @ab, how can the clients get to know this?
  c, we can now retry executing BatchSend using the backup copy of TSQLRestBatch we saved earlier.

@Erick, I'll be willing to buy your ebook when I actually start using EWB (at least when it's code complete feature is ready.

You are welcomed! I'll try my best to get mORMot prosperous

Thanks! I was just waiting for this after seeing the commit of the new FishShop sample, because I'm interested in learning how to make my program running as a system service under both Windows and Linux