I renamed a table in an SQL table and then used Workshop's 'update metadata' function to try to synchronize an ALDSP project that used the renamed table. So now I had two physical data services for the renamed table, one for the old name and one for the new name. The new data service had none of the relationships, presumably because ALDSP was not smart enough to find the foreign keys that involve the existing tables (fair enough). So, I tried some hand surgery to copy the relationships from the old data service into the new. Bad idea. ALDSP kept trying to second guess me and started modifying (and even commenting out!) data service functions all over the place. It got so tangled up that my only recourse was to blow away all the physical data services and rebuild them from scratch. Ouch. Moral of the story -- when you rename a table, hand edit the corresponding physical data service to match.
... until the collector arrives ...
This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)
Blog Archive
-
▼
2006
(135)
-
▼
Aug 2006
(20)
- ALDSP Null Pointer Exceptions
- ALDSP Update Order
- ALDSP Cascaded Deletes
- ALDSP vs. Multi-table Updates Again
- ALDSP Invalid SQL Specified
- ALDSP Primary Key Not Provided
- ALDSP Recursive Type Definitions
- ALDSP vs. Multi-table Updates
- MS SQL Server Enterprise Manager vs. BEA WebLogic ...
- ALDSP vs. Renaming Tables
- Storing Original Units of Measure
- Submitting AquaLogic Documents
- Data Models
- Python IDEs
- Ant, WebLogic 8.x, JDBC Connection Pools
- Changing ALDSP End Points
- JMX Consoles: MC4J, EJAM, jManage
- JUnit 4.0 BeforeClass Annotation
- Clay
- HTAs
-
▼
Aug 2006
(20)