Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM SQL » View Thread |
Messages 1 to 9 of 9 total |
DBISAM 3.1 with Firedac via ODBC |
Thu, Aug 8 2019 1:20 PM | Permanent 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 PM | Permanent Link |
Raul 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 PM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent 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 PM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Phil
Final thought - what happens if you set Firedac to use a NULL placeholder? Roy Lambert |
This web page was last updated on Thursday, March 28, 2024 at 08:36 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |