Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 9 of 9 total
Thread DBISAM 3.1 with Firedac via ODBC
Thu, Aug 8 2019 1:20 PMPermanent Link

Phil Frank

MealService Software

I have to write an add-on to an application running on DBISAM 3. I'm trying to use Delphi 10.2 and Firedac queries against a table that has an AutoInc primary key. I'm encountering an issue with a simple query (Select * from Table1). On an insert, Firedac recognizes the autoinc field and creates a -1 temporary value for the AutoInc value. When I save the changes, I'm getting an "Exact update affected [0] rows, while [1] was requested." error.

I've used DBISAM 3 with Firedac before, but apprently not in any situations where a user can update a table. I think I can work around the issue by immediately calling a post and refresh after the insert. But then I have an issue with the cursor landing on a different record, and a host of other issues around which I have to work.

This is the first time I've encountered this error. Any insights?

Phil Frank
Thu, Aug 8 2019 2:09 PMPermanent Link

Raul

Team Elevate Team Elevate

On 8/8/2019 1:20 PM, Phil Frank wrote:
>
> I've used DBISAM 3 with Firedac before, but apprently not in any situations where a user can update a table. I think I can work around the issue by immediately calling a post and refresh after the insert. But then I have an issue with the cursor landing on a different record, and a host of other issues around which I have to work.
>
> This is the first time I've encountered this error. Any insights?

That is some seriously old DBISAM there - circa 2002 ?!

I would suggest enable Firedac extended logging and see if you get a
better error message back on what exactly is going on (tracing i think
it's called).

Raul
Thu, Aug 8 2019 2:30 PMPermanent Link

Phil Frank

MealService Software

Raul wrote:

> That is some seriously old DBISAM there - circa 2002 ?!

Yeah. The application's being rewritten. This is a stop-gap measure.

> I would suggest enable Firedac extended logging and see if you get a
better error message back on what exactly is going on (tracing i think
it's called).

Thanks, I'll take a look. I see I accidentally posted this to the SQL discussion. I was aiming for the ODBC discussion!
Fri, Aug 9 2019 2:53 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Phil


I endorse Raul's concept of getting more detailed information. I'm wondering about

<<Firedac recognizes the autoinc field and creates a -1 temporary value for the AutoInc value>>

If that -1 is posted to the table then after the first time you'll create a primary key clash.

Roy Lambert
Fri, Aug 9 2019 1:54 PMPermanent Link

Phil Frank

MealService Software

Roy Lambert wrote:

Phil
I endorse Raul's concept of getting more detailed information. I'm wondering about
<<Firedac recognizes the autoinc field and creates a -1 temporary value for the AutoInc value>>
If that -1 is posted to the table then after the first time you'll create a primary key clash.
Roy Lambert

The -1 key is a placeholder (and is configurable). If a second record is created it's assigned -2. They get replaced when the record is refreshed.

I'm working on creating a trace log, but in the interim have discoved that accessing DBISAM through ADO and ODBC seems to work OK.
Fri, Aug 9 2019 4:20 PMPermanent Link

Phil Frank

MealService Software

Well, I was mistaken that the ADO ODBC interface worked. I'm getting essentially the same error. If I have a "Select *' query, where the table's primary key is AutoInc, when I append a row, the key is temporarily set to zero. The key only gets updated (in the query) if I close and reopen the query. So Appending and just Posting isn't sufficient, and I eventually get the error "Row cannot be located for updating. Some values may have been changed since it was last read.".
Sat, Aug 10 2019 3:13 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Phil


As I said I haven't used DBISAM for ages but what about calling query.refresh, or if you can for this part of your application use a table instead?

Roy Lambert
Sat, Aug 10 2019 9:14 AMPermanent Link

Phil Frank

MealService Software

Roy Lambert wrote:
what about calling query.refresh, or if you can for this part of your application use a table instead?


Calling Refresh was the first thing I tried. That didn't do the trick. Using a table does work. When a record gets inserted and post is called the Firedac component immediately recognizes that a Key has been assigned to the record (unlike with the FDQuery component). Fortunately, I think the only place I encountered this issue was where the user added/edited records. All of the other queries work as expected.
Sun, Aug 11 2019 2:52 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Phil


Final thought - what happens if you set Firedac to use a NULL placeholder?

Roy Lambert
Image