On 7/6/2021 10:30 AM, Mirco Malagoli wrote:
> Table.Append()
> Table.FieldByName= ...
> Table.FieldByName= ...
> Table.Post()
> myGUID= Table.FieldByName("GUID")->AsString
> but sometime i receive a NULL value and other time a wrong value.
....

> What is the correct way?

What you were doing should work OK - once you post you should be on the
inserted record and see the GUID.

Only reason i can think of this not happening is if the table is
filtered somehow - either filter or range is set.

Otherwise if this is the GUID then yes you can just generate one in code
and assign when populating the record. GUID would be unique either way.

Raul

Mirco Malagoli wrote:

> Roy Lambert wrote:
>
> Mirco
>
>
> You need to use SQL and check the LASTIDENTITY (Secion 9.14) in my
> pdf manual
>
> Example from the manual
>
> SELECT LASTIDENTITY('Customer', 'CustNo') AS LastCustNo
>
> Roy Lambert
>
>
> Sorry but the field is definited as GUID, the LASTIDENTITY for me
> always return 0 This is the table definition
> "CREATE TABLE "giri"
> (
> "idx" GUID COLLATE "UNI" DEFAULT CURRENT_GUID NOT NULL,
> "prog" INTEGER NOT NULL, ...
> )

My idea would be, adding an indexed column:
INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 0, INCREMENT BY 1)

and use this as link for all other tables or at least for getting
LASTIDENTITY ... but if you have to work with thousands of records it
will slow down everything if you query for "select guid from mytable
where myid=(LASTIDENTITY)".

What about adding a trigger with Action "AFTER INSERT" and save the
GUID_Value into another table (vTablename varchar, vLastGuid) so you
can query this for new records.

--
--
Yusuf Zorlu | MicrotronX

Raul

That is a very good point.

My guess from the table creation code fragment posted was that the GUID is used as the primary key but immediately after posting the table cursor should still be on that record so it should be possible to just read it unless something happens in between. I wonder if its a difference between Append and Insert (I know it shouldn't be) - I don't recall ever using Append. Certainly not in ElevateDB

Roy Lambert

On 7/9/2021 3:05 AM, Roy Lambert wrote:
>
> My guess from the table creation code fragment posted was that the GUID is used as the primary key but immediately after posting the table cursor should still be on that record so it should be possible to just read it unless something happens in between. I wonder if its a difference between Append and Insert (I know it shouldn't be) - I don't recall ever using Append. Certainly not in ElevateDB
>

Roy,

EDB implements both Append and Insert.

Append historically added record to the end while Insert added at the
current position of dataset.

However this should not matter with modern SQL databases like EDB since
all that logic is db engine controlled these days and not in code- i
definitely do not know "where" the record is stored and even how logically.

I would try figure out why GUID is not always available - especially
since it's sometimes OK so we know it works.

Is it simple filter/range issue, is table part of master/detail or is it
maybe some databound UI control interfering and moving record, etc  !?

Raul

Raul

>i
>definitely do not know "where" the record is stored and even how logically.

Strangely enough neither do I, nor do I really care. I know Tim reuses "deleted" records to save space and that's the extent of my interest

>
>I would try figure out why GUID is not always available - especially
>since it's sometimes OK so we know it works.
>
>Is it simple filter/range issue, is table part of master/detail or is it
>maybe some databound UI control interfering and moving record, etc !?

Probably but I'd guess we'd need to see a fair chunk of the program to figure that out. As you surmise its very very very unlikely anything in Tim's code (since I don't have the source I can't say definitely). Taking another look at the original post its finally registered with me that Mirco isn't using Delphi so connected via ODBC. Again shouldn't have an impact but who knows with computers. One thing it does mean is that there's little point in me playing round to see if I can replicate the problem.

Roy

Just for completeness of information.
I am using c ++ directly with TTable and TEDBDatabase.
I need to use TTable because the visualization DBGrid is connected to the same component, which can be filtered by the operator even if no one has touched filters or ranges in the tests.
The reason for GUID instead of Autoinc (simpler and faster) is that records created by other programs are imported into the same table

Mirco

Thanks for that

>I am using c ++ directly with TTable and TEDBDatabase.
>I need to use TTable because the visualization DBGrid is connected to the same component, which can be filtered by the operator even if no one has touched filters or ranges in the tests.

That I would say pretty much confirms Raul's guess.

I hope you meant TEDBTable and not TTable

I've been in a similar position and I would advocate either table.disablecontrold and table.enablecontrols whilst performing the insert or (my favourite) have a second instance of the table, perform the inserts on that and issue a refresh to the viewed table at intervals. When <<(in some situations I have to insert several thousand records and the work doubles).>> the amount of time taken up by screen refresh generally outweighs everything else.

Roy

Yes certainly TEDBTable sorry.
Obviously when I insert many records the UI grid is deactivated, but I don't want to use 2 different functions for normal insert and for import to avoid future maintenance problems.
The fact of not using 2 TEDBTable (right this time) one for the insertion and one for the UI is due to the fact that the operator needs to see each record inserted at the moment of insertion (it is an application that records production data in real time that inserts data upon the occurrence of certain conditions that the operator knows)

Mirco,

If you're still seeing this issue, please try to distill it down to a small project and see if it still happens (or test in the EDB Manager).  If it doesn't happen anymore (which it won't ), then you've got an issue with a "fly-away", meaning that once the row is added, the current row moves to satisfy a filter or range (or possibly navigation due to another dataset event like AfterPost), thus giving you the results that you're seeing.

Tim Young
Elevate Software
www.elevatesoft.com