Howdy all.

Well, I finally came to my senses and attempted to delete the Sequential Key Counter from my Products database. Unfortunately, this wasn't as easy a process as I'd hoped. Certainly not an intuitive process.

I removed the calls to SEQKEY in the dictionary for the key, removed the call in the default for the form property and relaunched the form to test. There, before gawd and everybody, the message to set the sequential key value appeared. So I made sure the calls in the dictionary and the form were in fact gone (they were) and tried to delete the entity from the repository. Unfortunately, it reported that %SK% was not there or was inherited or some other lame excuse, so that didn't work. I found a previous question here re: editing %SK% via System Editor. Managed to open the record but can't delete it from System Editor. I even launched ARev and deleted %SK% but OI still is finding a call to the sequential key.

Where did I go wrong and how can I get rid of this annoying, cloying little devil?

Thanks,

Mike

Mike,

You say you found and deleted %SK% in the repository. Don't you mean your table's DICT?

¹⁾)

- Oystein -

Oh gawd! I don't know what I mean anymore!!!

In ARev, I found %sk% in the dict, which I deleted. I also found %sk% in OI in the database components for the PRODUCTS file (in the repository), but no matter how hard I tried or how nicely I asked, OI would not delete it here.

I removed the SEQKEY call from the default property for the field (pardon me for reverting to ARevese). Long story short, in all the places I could figure to remove the call to SEQKEY, it was removed. As far as the dictionary (ARev and OI) records for the key field, they're just simple, every day, run of the mill field definitions. And still the bloody thing wants to treat it like a sequential key.

So, let's just assume then that I've done nothing. How would you turn a sequential key counter BACK into a plain old common key field?

Mike

Did you try recompiling the form? I believe the form stores its own version of what was in the dictionary at the time the form was compiled.

Therefore, remove reference to %SK% in the dictionary, then recompile the form, then it should all be gone - without a great drama.

Robert - Mike seems to say he's done just that.

Wait a minute - you say "remove reference to %SK% in the dictionary". That might be it. It's not enough to remove the %SK% dict row. Perhaps it's not even necessary. What one must do is to clear the seqkey default setting(s) other places in the dict.

There's one in edit line 29 of the dict row for the key field. (Although the DICT_EQUATES says line 29 is "SQL default value for insertions", which doesn't sound very relevant to me.)

And there's one in line 13 of the %FIELDS% row. (Although one would think the latter setting was generated from one in the key row.)

Right?

(I took an interest because I have a few new tables that need a seqkey. I have such tables in an earlier app of mine, but on closer inspection I see I never set the seqkey default in the dict, only in the forms. Seemed to work for me. Anyway - this means my old dicts haven't got the seqkey references. That's why I was so slow to catch up now.)

- Oystein -

Hi Oystein

Perhaps I could have been clearer but it sounds like you managed to decipher successfully. I meant if you go into the Table Builder, open the relevant table, remove the reference to SEQKEY in the default column, save the changes, then recompile the form, then that will remove the default sequence key from displaying on the form.

The reference to SEQKEY is also stored in the form which is why the form needs to be recompiled - at which time it will pick up whatever is in the dictionary.

For what it is worth, I happened per chance to discover yesterday that the default for a field is indeed stored in field 29 of the dictionary record even though the description in DICT_EQUATES is a little obscure ("SQL default value for insertions."). This is the animal which needs clearing - not the %SK% record.

Robert

Robert & Oystein,

Thanks for your attempts to make this clearer for me but it doesn't seem to be working. I really, honestly, hate to be a pest about this but this problem is on the verge of making me burst into flames.

Here's what I have already, repeatedly, done:

In OI:

Open Table Builder and for the Key Field properties, removed SEQKEY from Default.

Open Form Designer, open the PRODUCTS data entry form. In Edit Line Properties for Key Field, removed SEQKEY from Default.

I have no idea what you mean by recompile the form. I have saved and test run the form and continue to get the next sequential key number appearing in the key field.

This application has not been deployed yet as I'm still designing and entering old data.

So, after doing all of the above and STILL getting that gawd-blessed key counter, I close OI completely and go into ARev. Access the PRODUCTS dictionary through the editor (TCL: "Edit dict products *") and scroll through to %SK%. Deleted (several times now) %SK%. No visible or discernable call to %SK%, or SEQKEY in %FIELDS% or %PROTECT.whatever% records.

Back in OI (still in development mode):

Look in the repository under OpenInsight/Database Columns there STILL appears PRODUCTS.%SK%. Synchronize the database. Still there. Highlight this entity, select Entity, Delete from menu bar, error message: "Entity PRODUCTS.%SK% is protected, is inherited from another application or does not exist. Deletion of this entity is not allowed from application PINUSA."

ARGH.

Open the PRODUCTS form in OI, got the Sequential Key Reset message.

This is really starting to annoy me now.

Go back into AREV and issue TCL command "DELETEROW DICT PRODUCTS %SK%" Result: One Record deleted. Huzzah. I've been here before.

Back in OI. Find in the repository the record for the PRODUCTS form. Entity/Properties. Click on Recompile. Ok. Nothing happens.

Find again PRODUCTS.%SK% in the Database Components, Entity/Properties/Recompile. OK. Nothing happens.

Open (System Monitor: "Exec products") Products form. Guess what?

"The sequential counter %SK% is empty. Enter an initial value."

Is it just me or should this be infinitely easier?????????????

Gawd help me if I make another foolish mistake as this.

No fooling, this is really frustrating me. At least in ARev when nonsense like this would happen, there was a way to break into the thing to fix it. I just don't know how to do it in OI, or even if such can be done. Kinda like automatic vs manual transmission. I prefer manual so as to have better control over the engine. Sure, ARev had it's faults but at least you could FORCE it to obey you…usually. I don't feel the same about OI.

I'm sure it'll end up being something horribly easy.

Mike

Mike,

Recompiling the form: When you save the form in Form Designer it's recompiled.

You can do a more thorough compilation of a form using Entity | Compile with Tree Compile ticked (from OI's main window). Tree Compile will "compile an entity and all entities upon which it is dependent. Such entities would include the controls in an OpenInsight form" (quoted from the online docs). I don't know if Tree Compile would make a difference in your situation.

But what Robert says is you should clear line 29 of the key field's dict row. With System Editor open table DICT. row and erase that SEQKEY in line 29.

I hope this helps. If not - be my guest - be a pest!

- Oystein -

Oystein,

Thanks for the tip. I've not gotten used to OI's System Editor but I see it works similarly to ARev's editor.

Line 29 of my keyfield in DICT.PRODUCTS is blank. There is no value on that line whatsoever.

Now whaddoido?

Mike

Mike,

Dunno. Reformat the harddisk?

Sorry.

I did what I should have done long ago: Made a table and a form and tried it for real. I get the symptoms you describe. And I got rid of them by taking Form Designer, deleting the key control, and creating it again.

I don't think it's anything in the dict or the form itself. Must be some other component - some repository entity.

- Oystein -

Could somebody with a bit more sequential key counter experience than me point out the advantages and disadvantages of having SEQKEY set in the dictionary? The few times I've needed a sequential key I've set SEQKEY in the default of the control key in one or more forms bound to the table, but not in the dict. Now I have to make a decision for a new table I've created.

- Oystein -

SEQKEY is implemented at the form level.

Setting SEQKEY in the dictionary should just instruct the form_designer to use a SEQKEY when you paint new forms, so you do not need to set the property in every form.

If you look at the dropdown for DEFAULT entry in the prompt details window you will see ] and ] at the bottom of the list.

] is the default. This means use the entry from the dictionary.

but I changed the dictionary ….

When you compile a form it retrieves the value from the dctionary and compiles it into the form.

If the dictionary value changes after the compile the window will not pick up the change.

but I compiled the window ….

Openinsight checks timestamps when it compiles. IF nothing has changed since the last compile then it does nothing.

To force it to recompile a window and thus incorporate changes you need to opend the window in the form designer and touch something.

Finally, even if there is a SEQKEY in the dictionary, if you choose something else for the DEFAULT setting in the prompt details window it will

override the dictionary setting. Choose ] for no default.

Hope this helps,

Bob

Bob,

Embarrassingly simple. Thanks.

Hope it explains everything for Mike too.

- Oystein -

Sounds good to me in theory. I'll give it a shot.

Thanks,

Mike

Oh my gawd!! It worked!! Yes, EMBARASSINGLY SIMPLE!!

I could have saved myself a lot of lost hair over this one!

Mike

View this thread on the forum...