|
|
|
Forum Guru
 
Group: Forum Members
Last Login: 2010-09-01 18:43:03
Posts: 61,
Visits: 285
|
|
Hi,
I have an application where I need to extract the reports that are stored in the database and then copy them into another database at a client's location. I created an application to extract those reports and store them in a temporary database file. And, then I have another application that imports(update or insert) those reports into the client's database. For the extracting and importing, I'm using ADO.Net directly. The ECO_ID is a GUID. When importing into the client's database, I make sure that the ECO_TYPE field matches the class name, by querying the client's ECO_TYPE table for the corresponding class. But, those new reports are not displayed in the client's copy of the application, although I can verify that they are in the database(by using a DB management tool).
Is there something that I'm missing?
Best Regards,Daniel Rail
Senior Software DeveloperAccra Solutions Inc.(www.accra.ca)Accra Med Software Inc. (www.filopto.com)Blog (railoffice.dyndns.org)
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: 2010-09-01 18:43:03
Posts: 61,
Visits: 285
|
|
I just tried adding the ECO_ID to the ECOMODELROOT table and that worked. But, now it doesn't want to evolve the database.
Best Regards,Daniel Rail
Senior Software DeveloperAccra Solutions Inc.(www.accra.ca)Accra Med Software Inc. (www.filopto.com)Blog (railoffice.dyndns.org)
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 09:40:19
Posts: 268,
Visits: 2 465
|
|
danielrail (2010-05-20)
I just tried adding the ECO_ID to the ECOMODELROOT table and that worked. But, now it doesn't want to evolve the database.
It's possible the ECO_ORMAPPING info in the DB is different in the two databases and you are using the wrong ECO_TYPE
I wouldn't do what you are doing, I'd use ECO to create the objects.
====
Pete
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: 2010-09-01 18:43:03
Posts: 61,
Visits: 285
|
|
When inserting or updating in the destination database, here are the two statements that I'm using (and I'm using Firebird 2.5 RC2 and ECO 5.0, the latest daily build):
UPDATE OR INSERT INTO REPORTOBJECT (ECO_ID, ECO_TYPE, REPORTFILE, REPORTTITLE, SYSTEMCATEGORY, SYSTEMREPORT, ISFORM, REPORTDESCRIPTION) VALUES (@ECO_ID, (SELECT FIRST 1 ECO_TYPE FROM ECO_TYPE WHERE CLASSNAME='ReportObject'), @REPORTFILE, @REPORTTITLE, @SYSTEMCATEGORY, @SYSTEMREPORT, @ISFORM, @REPORTDESCRIPTION) MATCHING (ECO_ID)
UPDATE OR INSERT INTO ECOMODELROOT (ECO_ID, ECO_TYPE) VALUES (@ECO_ID, (SELECT FIRST 1 ECO_TYPE FROM ECO_TYPE WHERE CLASSNAME='ReportObject')) MATCHING (ECO_ID)
As, you can see, I grab the ECO_TYPE from the destination's ECO_TYPE table. After performing this, I do see the objects when running the application. But, after if I make a change in the ECO model, it's giving me an error when trying to evolve the database(TargetInvocationException was unhandled: Exception has been thrown by the target of an invocation: Object reference not set to an instance of an object).
And, after a little investigating, I tried with another database and everything worked fine(evolving the database, after performing the above SQL statements). All I can figure out at the moment, was that I probably inadvertently modified the ECO_ORMAPPING when I opened the record and scrolled through the blob.
Luckily, all of this is a test system where these errors are being encountered.
Best Regards,Daniel Rail
Senior Software DeveloperAccra Solutions Inc.(www.accra.ca)Accra Med Software Inc. (www.filopto.com)Blog (railoffice.dyndns.org)
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 09:40:19
Posts: 268,
Visits: 2 465
|
|
Creating the ECO objects is definitely the safest way to do this 
====
Pete
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: 2010-09-01 18:43:03
Posts: 61,
Visits: 285
|
|
Peter Morris (2010-05-21)
Creating the ECO objects is definitely the safest way to do this
I do agree.
But, for our scenario, we need to be able to update/insert the reports, that we distribute and that are not modifiable by the end-user, with a every new version of the software. And, for sure, using GUIDs as ECO_ID is the only way to go when doing this, otherwise, it will be asking for trouble.
Best Regards,Daniel Rail
Senior Software DeveloperAccra Solutions Inc.(www.accra.ca)Accra Med Software Inc. (www.filopto.com)Blog (railoffice.dyndns.org)
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 09:40:19
Posts: 268,
Visits: 2 465
|
|
danielrail (2010-05-21)
Peter Morris (2010-05-21)
Creating the ECO objects is definitely the safest way to do this
I do agree.
But, for our scenario, we need to be able to update/insert the reports, that we distribute and that are not modifiable by the end-user, with a every new version of the software. And, for sure, using GUIDs as ECO_ID is the only way to go when doing this, otherwise, it will be asking for trouble.
I've done the same in the past. Don't mess with the ECO_ID / SQL, just add an additional GUID to each object which has SaveAction=Freeze.
====
Pete
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: 2010-09-03 10:28:49
Posts: 173,
Visits: 2 010
|
|
| Does your class inherit from a non child mapped class? If so you need to add rows in that too. There should not be any "magic" involved in this, just a few things to keep in mind... But as a general note I do agree with Pete; it is easier and safer to just let eco create the objects and store them (it should however be possible to do what you do so something is not right with your setup).
|
|
|
|