Support Forums - View Thread

View Thread

The following is the text of the current message along with any replies.

Messages 11 to 20 of 22 total

DBISAM3 to EDB - problem with AUTOINC to GENERATED IDENTITY columns

Mon, Dec 16 2013 4:47 AM	Permanent Link
Uli Becker	Jeff, > Here is a sample project. When Roy asked, I groaned thinking of how to trim the project down (and how I had done so in the past taking many hours) but then decided to go the whole hog and build a little project from scratch. > The little project is attached - this is the first time I have "deployed" any EDB project so I'm not sure if I have given you all that is required. > Attached is a reverse engineered table and the source of the project that shows the problem. I just set up everything and tried it - no problems. All records are inserted without error. Though I converted your project to ANSI. When I've some time left later, I'll install it as Unicode - let's see if that'll make a difference. Uli
Mon, Dec 16 2013 5:33 AM	Permanent Link
Roy Lambert NLH Associates Team Elevate	Jeff >Here is a sample project. When Roy asked, I groaned thinking of how to trim the project down (and how I had done so in the past taking many hours) but then decided to go the whole hog and build a little project from scratch. > >The little project is attached - this is the first time I have "deployed" any EDB project so I'm not sure if I have given you all that is required. > >Attached is a reverse engineered table and the source of the project that shows the problem. Goodie - since Uli has tried it in ANSI and its fine I don't have to try I also don't have unicode so can't try that. So far we have 1. works in EDBManager, ANSI and (I assume) UNICODE 2. works in Delphi in ANSI 3. Doesn't work in Delphi in UNICODE (currently unconfirmed) 4. Your test project if it bombs using UNICODE at your end doesn't have anything visible (to me) that can cause the problem. At this point I think peer support has almost reached its limits. The only thing that we can still do is for someone with Unicode to confirm your project bombs. If it does I think you need to report to Tim, if not you need to examine your environment. Roy Lambert [Team Elevate]
Mon, Dec 16 2013 5:36 AM	Permanent Link
Uli Becker	Jeff, ok, I switched to the Unicode version (2.13) and tried your project. Result: Error when trying to insert a record. What I did now: 1. Remove all persistent fields: no error 2. Recreate all persistend fields: no error 3. Compare the persistent field with the recreated ones: Your fields: "Required" is checked on all fields = "not null" My fields: "Required" is not checked at all So remove the "Required" checks of all fields in your table component and your projekt will run. Though I can't tell you why, and as well can't tell you, why this problem only occurs with the Unicode version. I'd suggest to open a support ticket. Uli
Mon, Dec 16 2013 6:12 AM	Permanent Link
Roy Lambert NLH Associates Team Elevate	Uli >What I did now: > >1. Remove all persistent fields: no error >2. Recreate all persistend fields: no error >3. Compare the persistent field with the recreated ones: >Your fields: "Required" is checked on all fields = "not null" >My fields: "Required" is not checked at all > >So remove the "Required" checks of all fields in your table component >and your projekt will run. The Required flag is Delphi's internal way of saying NOT NULL, by removing that you've removed the requirement AT DELPHI LEVEL to check that a field isn't null before posting. I don't know what it means in terms of TDataset and actual data flow. Since you say this doesn't occur in the ANSI version it would suggest that a change was made in Delphi at some point. It also prompts a question for Jeff - how did he create the persistent fields? >Though I can't tell you why, and as well can't tell you, why this >problem only occurs with the Unicode version. >I'd suggest to open a support ticket. I agree with the conclusion. Tim needs to be involved. Roy Lambert [Team Elevate]
Mon, Dec 16 2013 7:55 AM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Jeff, << ------------------------------------------------ BUT in EDB I get this error message:- Project apm.exe raised exception class EDatabaseError with message 'Field 'AttachmentID' must have a value'. >> That's a TDataSet-level "required field" error message, which means that the TField.Required property is set to True. Did you perhaps set that property to True at design-time/run-time ? ElevateDB won't do this for required fields, it always leaves that property alone in order to avoid such issues. Tim Young Elevate Software www.elevatesoft.com
Mon, Dec 16 2013 7:58 AM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Uli, << Though I can't tell you why, and as well can't tell you, why this problem only occurs with the Unicode version. >> I don't think it does - I think the Required property was probably just toggled on at design-time for that TField. As I noted in my reply to Jeff, EDB doesn't set this property. In fact, it specifically turns it off in the TFieldDefs in order to prevent the TField.Required property from inheriting it: edbcomps.pas procedure TEDBDataSet.AddColumnFieldDef(ColumnPosition: Integer; Column: TEDBCursorColumn); ...... TempFieldDef.Required:=False; <<<<<<<<<<<<<<<<<<<<<<<<<<<< Here TempFieldDef.InternalCalcField:=SourceColumn.Computed; if SourceColumn.ReadOnly then TempFieldDef.Attributes:=TempFieldDef.Attributes+[faReadOnly]; {$IFNDEF FPC} TempFieldDef.FieldNo:=(ColumnPosition+1); {$ENDIF} end; finally EndUpdate; end; end; end; Tim Young Elevate Software www.elevatesoft.com
Mon, Dec 16 2013 8:29 AM	Permanent Link
Roy Lambert NLH Associates Team Elevate	Tim >That's a TDataSet-level "required field" error message, which means that the >TField.Required property is set to True. Did you perhaps set that property >to True at design-time/run-time ? ElevateDB won't do this for required >fields, it always leaves that property alone in order to avoid such issues. > I normally just double-click the table and press ctrl-F to get the persistent fields and in D2006 I don't get Required set to true. That's why I asked Jeff how he set them. The puzzling part is that the demo Jeff sent, when converted to ANSI by Uli works, and since he never said anything about it I assume that Required was still set to true as Jeff sent it. Roy
Tue, Dec 17 2013 8:48 AM	Permanent Link
Uli Becker	Hi to all, > << Though I can't tell you why, and as well can't tell you, why this > problem only occurs with the Unicode version. >> > > I don't think it does - I think the Required property was probably just > toggled on at design-time for that TField. Tim is right - I have to correct myself. Since the field definitions didn't macht (Ansistring vs. Widestring) I deleted the fields and recreated them. That's why the required property was not set in the ANSI version. Sorry about the confusion. Uli
Tue, Dec 17 2013 8:50 AM	Permanent Link
Uli Becker	Roy, > The puzzling part is that the demo Jeff sent, when converted to ANSI by Uli works, and since he never said anything about it I assume that Required was still set to true as Jeff sent it. Please see my answer to Tim's post - it doesn't work with the ANSI-version either. Uli
Tue, Dec 17 2013 9:13 AM	Permanent Link
Roy Lambert NLH Associates Team Elevate	Uli >Since the field definitions didn't macht (Ansistring vs. Widestring) I >deleted the fields and recreated them. >That's why the required property was not set in the ANSI version. That would explain it your part in it Now all we have to find out is why Jeff got Required in there to start with. Roy

« Previous Page	Page 2 of 3	Next Page »
Jump to Page: 1 2 3