Sorin


Sounds as though the original datamodule was being freed which would explain the AV but not why MadExcept didn't report it. Why adding a new datamodule in would prevent that I have no idea.

What happens if you take out the new datamodule, do things go back to AVing or work?

Roy Lambert [Team Elevate]

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
>
> Sounds as though the original datamodule was being freed which would
> explain the AV but not why MadExcept didn't report it. Why adding a new
> datamodule in would prevent that I have no idea.
>
> What happens if you take out the new datamodule, do things go back to
> AVing or work?

If I remove the new datamodule or move from auto-create forms to available
forms the AV return.
I also don't find any place where I freed the old datamodule before trying
to post.

Thanks
Sorin

Sorin


Set a breakpoint on the line before the post and see if the table still exists at that point.

Roy Lambert [Team Elevate]

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message

> Set a breakpoint on the line before the post and see if the table still
> exists at that point.

I did it.
I set a breakpoint on the post line and check the state of the ttable and it
show "dsInsert".

Thanks
Sorin

Sorin


Are there any 3rd party controls in the app? If so and you have the source make sure they're included in the search/library path and none of them have {$D-} in them. That way if its one of them it should break at the right point.

Last thought, compile with debug dcus and see if that will surface the culprit.

Roy Lambert [Team Elevate]

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote
> Are there any 3rd party controls in the app? If so and you have the source
> make sure they're included in the search/library path and none of them
> have {$D-} in them. That way if its one of them it should break at the
> right point.
>
> Last thought, compile with debug dcus and see if that will surface the
> culprit.


The only 3rd party controls are the elavatedb comp...

I remove the dcu file, recompile with the debugger and it pass ok.
Only on the runtime it raise the error.

I'll try latter to create all the datamodule from scratch, maybe this will
give me a clue.

Thanks for the effort
Sorin

Sorin


Another wild thought - do you have another variable with the same name as the table? Its one that's caught me before as things have gone in or out of scope.

Roy Lambert[Team Elevate]

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
> Another wild thought - do you have another variable with the same name as
> the table? Its one that's caught me before as things have gone in or out
> of scope.

No

Ok, what I find out is that closing a query, from another datamodule,
before trying to post myTable cause the AV.
If I close the query after the post it's run ok.

Since there aren't defined any relation between myTable and that query
I can't understand what is the reason of error.

But since the change is unimportant to my application I'll stop searching
here

Thanks again for the support
Sorin

Sorin,

<< Ok, what I find out is that closing a query, from another datamodule,
before trying to post myTable cause the AV. If I close the query after the
post it's run ok. >>

That's not good.  Can you send me your project source so that I can run it
here ?  I want to make sure that this isn't occuring in the engine itself.

--
Tim Young
Elevate Software
www.elevatesoft.com