Providing support for all E. Crane Computing products, including POWERGEN, PBSERVICE, HARPB, VERSIONEDIT, PBLRESCUE, and PBLEXPLORER.
You are not logged in.
Pages: 1
I have a nightly process that synchronizes all the day's changes with a reference copy of my application's pbls, then builds an executable for people to test/play with.
My first question: How does the synchronization process determine that an object has changed? Once an object has changed (and sometimes when it hasn't), that object is flagged as "changed" and re-imported by the synchronization process each night after that (using the same pbls and pbgs that got sync'd and regenerated the night before by the same process).
My second question: I'm getting a bunch of errors during the sync process's first pass that don't make sense to me. For example, I get a BUNCH of errors like "Error C0051: Unknown function name: setitem" on datawindow objects. Of course setitem isn't an invalid function there. I've ignored these errors in the past, because the "Re-importing objects which failed last Import Phase" has always cleared up things, and all the objects import just fine.
However, last night, I had an object fail import during the second phase with one of these non-issues. It wasn't something as blatant as setitem (it's a function written by me in another object), but the function certainly does exist, and existed (and was imported by powergen) with no problems on previous nights. I doublechecked the objects in question, and they imported from source control and regenerated in the PB front-end with no problems. (The function still exists, with the same signature as before).
Any ideas?
-J
I suppose some version information may help. :)
The application in question is a PB8.0.3 build 9704 app, and I'm using PowerGen Pro v5.0.0.6. The build process is running on an NT4 machine.
To your first question, PowerGen determines which objects have changed by comparing the source in the PBL with the source in the export file. We've seen cases where the import process (done through a Sybase API) changes the syntax enough for the comparison process to believe they are different. If you check in these objects (which performs an export), it may correct the problem for subsequent synchronizations. If not let me know.
On you second question it is very unusal for the first import pass to produce any errors. Could you send a couple of the objects that product these errors along with the output log. The import shoud produce no errors, so I need to investigate your issue with a few specific cases.
Regards,
Phil
Upon closer inspection, the errors I'm seeing are in the "Regenerating descendants of imported objects" and "Performing Phase 3 Import - Adding Full Object Information". Where should I send the logfile? Due to the complexity and levels of inheritance in this code, I couldn't really send you an object sample without sending a fairly giant chunk of the application (about 90Megs of code).
However, as I'm looking through the errors trying to find an object that would be somewhat easy to extract, I'm noticing a trend...the errors are produced when I'm referencing a datawindow through at least one pointer. For example, I'm referencing a pointer to a window, which has an instance variable which is a pointer to a user object upon which the datawindow is located. So, I'm saying:
some_window_pointer.some_uo_pointer.my_datawindow.rowcount ()
And the logfile reports that rowcount is not a valid function. Could PBORCA be having trouble determining that the object is a datawindow through that many references? I do see some other instances that aren't as extreme:
some_uo_pointer.my_datawindow.setitem... where some_uo_pointer is a variable passed by value to a function. But it appears that all of the errors happen when I'm not DIRECTLY referencing a datawindow (and they all appear to be datawindow-related functions, except for the crazy outlier case that didn't properly re-import on the second phase).
If this plus the logfile doesn't give you enough, I'll try to duplicate the import issues with a small test application and send that in. If that fails, maybe we can put together an NDA and I'll send you a CD with 90Megs of code on it. ;)
-J
I'm also noticing that all the datawindows throwing the error are several inheritance levels deep. All dws in my app inherit from either base_datawindow (which inherits from PB's datawindow object) or base_multi_row_dw (which inherits from base_datawindow).
All the instances of the error happen on dw's that inherit from base_multi_row_dw...although not ALL instances of dw's inheriting from that object are throwing the error.
-J
You can send the output lot to support@ecrane.com. I'll take a look at that before we go to the next step of getting a test case.
Regards,
Phil
According to the log file that you sent, your build is completing successfully in spite of the errors that occur during the import. These errors are corrected later in the process resulting in a clean build.
Phil
Pages: 1