| M.P. van Dobben de Bruijn 2005-07-29, 8:59 am |
| On Wed, 27 Jul 2005 19:46:37 UTC, "M.P. van Dobben de Bruijn" <Reply2Usenet-2005@The-Net-4U.com> wrote:
> On Wed, 27 Jul 2005 13:02:49 UTC, "Leonid Chudakov" <chudakov@klarisoft.com> wrote:
>
>
> From the commenting in the example code
> in the manual I understood it is supposed to
> be Red/Write Deny None and hence the LOCK
> statement on the next line (commented for Exclusive
> access). Are you sure that 42h is also locking it to me?
>
>
> I embedded it in the Main (not Window but Frame of course)
> Procedure of the application. In the Open Window and then it
> goes before the generated code. If I look at the source it is then
> in the main LOOP handling all events and on OF EVENT:OpenWindow.
>
> But ...... I stil had problems. Until I looked thoroughly
> (or perhaps after having some extra coffee a little bit mo-
> re thoroughly) at the directory with the .DBF-files. Then dis-
> covered that the first key was generated KeyName.IDX and
> the second one did not get that far KeyName.$$$. So I looked
> in the dictionary, the Primary Key was using an unique number of
> one of the fields, the second key used that same field but had ano-
> ther non-unique fields prefacing that one. I nevertheless wanted to ha-
> ve the componented whole key to be unique. Perhaps something wrong
> with that. Sure enough ... when I dropped the unique requirement for the
> second key from the dictionary it worked without a hitch. The problem imme-
> diately returns of course (even GPF-ing) if I put that unique requirement in again.
>
> So there must be something wrong with that secondary key of two components.
>
> Could it be that if the data is contaminated with non-unique combo values
> this translates to this kind of behavior instead of graciously dropping to an er-
> ror message (with full details) and then out of the key-generation and/or programm?
In the thread above I expressed that I thought Clarion
for Windows Templates fails "elegant" handling of corrup-
ted keys / indexes in contrast to the DOS-version. I have to
apoligize here for this misinterpretation of Clarions Win templates.
I found that the GPF'ing occurs only if I have a
(obviously uninterpretable or illegal) structure for
the key in the dictionary. Could be that the key (it
fails to GPF if I put the Unique attribute in the key's
spec, but rebuilding the key does not fail if that one
is not there) is illegally structured. Or that the existing
data contains illegal values in combination with that u-
nique key's specs at least. If I leave it out there is no pro-
blem in rebuilding the keys at all. A windows pop up saying
that the key-file has to be rebuild because it is corrupted. That
is then done transparantly in the background (for <g> legal keys).
So I apologize for the confusion on my part
and which I perhaps created by others on this.
The dealing with corrputed keys is as elegant as ever.
Now ... <g> one minor note. The pop-up window
says that the key has to be rebuild (future tense) and
I have the impression that is going on in the background
already. So it should remark in "active tense" I believe it is.
The key of ..... is corrupted. Your application is
(re-) building it for you at the moment. Please wait ...
But then the OK-button on that pop-up gets illogical <VBG>.
--
regards from Leeuwarden
Peter van Dobben de Bruijn
----
reply2usenet-2005 .at. The-Net-4U.com (.at. becomes @)
----
|