Toad World® Forums

logical to physical error TPERDomain.ReplaceConsolidatedObject


#1

Hi,
I am trying to convert a logical model to a physical model (Postgres 8.2). I open the convert dialog and immediately click on the ‘execute’ lightning bolt and I get an error that includes the following message:

Internal Error - TPERDomain.ReplaceConsolidatedObject(ID, List.Name = )

Any ideas on how to resolve this? 3.1.1.166

Added note: Now when I go to close TDM I get the following error and it won’t close:

Error - Access violation at address 00D364B7 in module ‘TDM.exe’. Read of address 00000000

I am using AVG 7.5.503 as my antivirus. This is the commercial ‘paid’ version of AVG, not the free one. I include this as I noticed on other posts with a similar/same error that you think this involves the antivirus program. I disabled the antivirus program and tried again, and still no good.

Message was edited by: BillR


#2

I had this problem before too,

see thread
http://modeling.inside.quest.com/thread.jspa?messageID=13773&#13773

they corrected my model, but I’m not sure if someone was looking deeply into this problem.

And now the same happened to me again, and again on the same model, that was already corrected. I only added it to version manager, made some changes, saved and now I cannot open it.

Maybe some internal check after save (hidden load and check with model in memory) would be good, so that TDM does not create broken models when saving.
There is some problem with XML saving/parsing. Maybe the saving lacks validation of XML file it creates.


#3

Hello Bill and arki,

We would like to ask you to send us your logical model. We need to verify it to find out what causes the problem. (One model will be enough.) Please send it to: modeling@quest.com.

Thanks very much in advance!

Regards,

Vladka + TDM Team


#4

sent email to the address you posted vladka


#5

Got it. Thanks Bill!
As soon as I know more, I’ll let you know.

Have a nice day.

Vladka


#6

Hello Bill,

Thanks again for providing us with your model. We have managed to simulate the problem and found a bug in TDM3. We will fix it. CR # 41 034.
Our developers are dealing with this task at the moment.

Thanks again!!

Vladka


#7

Hi Vladka,
is there any more info than this? e.g. Does this affect anything else other than converting from a logical to a physical model? Is there a system we can follow this with given the CR number? Etc. Etc. Etc.

I’m thinking of purchasing the commercial version, but understandably don’t want to purchase anything unless the things I use it for work, and I know what limitations issues there are with it. :slight_smile:

Thanks for looking at this by the way.

Cheers,

BillR


#8

Hello Bill,

I’m afraid, I need to ask you for patience. Our developers are still working on this. Unfortunately, other problems similar to the yours have been reported (Arki has also raised the issue…), and now we are trying to find out connections and further verify what, where, how, why… We have several models we need to check out, test etc.
So, please wait till the next week. I believe, I’ll have some good news for you then.

Thanks very much!

Vladka


#9

Just a quick update on this issue.
We have verified all available models where the problems occured, and till now corrected most of them. Unfortunately, we still haven’t found the cause of the problems and therefore keep dealing with this task. CR # 43 365.

As soon as I know more, I’ll write again.

Vladka


#10

Hello Bill,

I’m pleased to inform you that CR # 41 034 has been fixed. The fix will be implemented in next TDM3 version.
There was a problem with expanding keys during decomposition of M:N relationship.

Thanks very much for your co-operation and patience!

Regards,

Vladka + TDM Team


#11

is there any E.T.A. for this? thanks by the way. looking forward especially to seeing the identifying relationships work properly with serial data types and serial based dictionary types.


#12

Hello Bill,

Next commercial release is planned for the end of the 1Q of the year.
Next Beta will be launched in February.

looking forward especially to seeing the identifying relationships work properly with serial data types and serial based dictionary types.

Just to be sure, you refer to the following thread, don’t you?
http://modeling.inside.quest.com/thread.jspa?messageID=14772&tstart=0#14772

CR # 43 192 - PG 8.2 bug - data type in the child table for said column MUST BE an INTEGER, NOT a SERIAL.

This problem has already been fixed for next release.

Just a note: you write:

…and serial based dictionary types.
Unfortunately, it’s not possible to create serial based dictionary type in PostgreSQL. Please correct me if I’m wrong.
Or do you mean domain with serial data type?

Thanks.

Regards,

Vladka + TDM Team


#13

Unfortunately, it’s not possible to create serial based dictionary type in PostgreSQL. Please correct me if I’m wrong.

Yes, you are wrong :slight_smile: See attached screen shot (I’m not sure of the difference between attach image and attach file, so my apologies, I did both).

Yes that is the CR I am referring to. So I can expect to ‘test drive’ the fix in February. Thank you for the info.

Regards,

BillR
Serial_Dictionary_Type_Postgres.jpeg


#14

Unfortunately, it’s not possible to create serial based dictionary type in PostgreSQL. Please correct me if I’m wrong.

Yes, you are wrong :slight_smile: See attached screen shot (I’m not sure of the difference between attach image and attach file, so my apologies, I did both).

Yes that is the CR I am referring to. So I can expect to ‘test drive’ the fix in February. Thank you for the info.

Regards,

BillR
Serial_Dictionary_Type_Postgres.jpeg


#15

Hello,

Unfortunately, it’s not possible to create serial based dictionary type in PostgreSQL.

I mean PG database does not allow you to do it. (It’s not possible to create serial dict. type in PG database.)

Some more explanation:
TDM3 allows you to create a dictionary type in PG model. It is not forbidden.
However, to Model | Dictionary Types, PostgreSQL domains (PG domains) are entered. PG domains are not the same as domains in TDM3*.
What you enter to dictionary types section in TDM3, it will be generated in final SQL script.

*TDM3 domains (Model | Domains) have only a logical meaning and are not generated in final SQL script. If a domain is used in attribute, only values of the domain are transferred to attribute during the DDL script generation process.
The problem with Serial data type in domains is registered under CR # 44 376 and has not been solved yet.

Thanks.

Regards,

Vladka


#16

I don’t think you should bother to try to solve serial data types in domains for Postgres as Postgres does not support this. I asked about this on the Postgres mailing list some time back, maybe a year and a half. The response from one of the Postgres people made sense but basically said, no you can’t put a serial data type in a domain in Postgres. Refer to the following link for more detail.

http://archives.postgresql.org/pgsql-sql/2006-12/msg00192.php

Bottom line is don’t pull your hair out on this one, Postgres doesn’t support serial data types in domains either.


#17

Thanks for the info.

Yes, we’ll deal with serial data type in TDM3 domains (not PG domains). :wink:

Regards,

Vladka