BTW, Nadya,

Oddly enough, in researching this I looked at Tastrade. Didja know they use APPEND BLANK in the AddNew method of the superclass? And in the DBC, there is a NewID function which grabs a sequential number from a "Setup" table. Is this what you are basing your framework on?

Where this applies to your issues is that it runs headlong into a personal preference of mine: avoiding code in the DBC. I don't like procedural code in Fox DBCs, although when it comes to server databases I'm the opposite (tons of stored procs).

>Do you have code universal enough for this kind of situations? Could you please show it?
>
>Thanks in advance.
>
>>Hi Nadya,
>>
>>I would rethink using APPEND BLANK in your framework if I were you. What I do is a method that accepts the table and primary key value and primary key field. Then I use INSERT INTO ... () VALUEs (). APPEND BLANK is going to cause problems, especially if the app comes down and a blank record gets left in the base table. Thereafter, the app will break the next time an APPEND BLANK is issued, as you are finding out.
>>
>>
>>>>Yup. Generate the value and use INSERT INTO instead of APPEND BLANK. Create the PK value before the INSERT.
>>>
>>>Append blank is in our FrameWork :( I don't want to write special code for this particular form, though it seems like I must.
>>>
>>>>
>>>>>Hi everybody,
>>>>>
>>>>>I have a table, there field Code (Character 6) is made PK. This table contains one blank record (this is by design). Now, each time I'm issuing append blank, I get an Error "Uniqueness of indexes is violated". I'm thinking about adding a default value for this field, but I don't want to use NextID table approach, because this database doen't have a NextID table and I don't want to change it.
>>>>>Therefore I'm seeking for the idea of a function, which will generate Unique ID automatically (Char 6).
>>>>>
>>>>>Or may be you have other ideas? Simple way, which was suggested by my manager, just make this index to be regular and deal this checking on the form level. I disagree, because our data is not secure enough, so if somebody will edit this table directly, there is a chance for adding duplicates.
>>>>>
>>>>>What do you think? I know, it's not recommended to use character PK (meangful), but this table was designed long time ago and I don't want to change it.
>>>>>
>>>>>Thanks in advance.