Using 15.1.3 on a 64 bit server, I am trying to publish the UD business objects using Tools > Utilities > UD fields.
Problem is when I click Build All it comes back 'unknown failure'. I've retried like 5-6 times to no avail.
I've even submitted to ASI and after uploading a copy of the db, they were able to publish from their server but i still cannot on mine.
Can anyone think of anything I could be missing on this?
I've been trying to get a very simple Member Type constraint to work but am having no success.
What I've done so far is added a property constraint to NetContact and CsContact Member Type field with the following code:
string proposed = (string)proposedValue;
proposed = proposed.ToUpper();
if (proposed == "CH")
constraintPassed = true;
I think this constraint should return an error if the selected record's member type changes to something other than CH. However when I select a record, go to the Personal link, change the member type to something other than CH and save, I do not receive an error.
Hello,
I have created a business object in BOD and somehow saved it with the wrong properties and published. Now when I try to open BOD from iMIS I am getting following server error:
---------------------------------------
The SQL returns 3 rows and the rows shows an array of 4 rows including the field names.
Normally the ds would be filled with a data adapter.
private DataSet getCommitteeCodesObject(Guid transactionID, string credentials, string error)
{
DataSet ds = null;
Asi.iBO.ContentManagement.CWebUser user = null;
try
{
The error extract that is contained below comes from the application event log from the App server. It is registered every time any of the following are attemepted:
Try to create a new object - when selecting the table to include in the Database tab.
Try to add a new field into an existin object
Try to create objected from the user defined tables
In order to try to address I have:
Run a series of functions from the DB Repair utility
Rebuilt the business objects using the DB Upgrader
Run a trace and extracted the SQL, run it, and had no errors returned.
I also had a look through the Community and thought that this link was relevant (but beyond my scope of understanding). http://www.imiscommunity.com/refreshing_view_meta_data_revisited
When I ran the 2nd query in this item I got the following
vGroupInfo The object 'vGroupInfo' does not exist or is invalid for this operation.
This object was the only item not in the list of the first query,
I have a customer on 15.1.3 initial release. We upgraded them from 15.1.2 over a week ago. We had a problem last weekend where a member was getting an error when trying to update his record. The error indicated that the CsContact.UpdatedBy field was not long enough - 15 characters. I contacted TS and went ahead and changed the field length in the BO to 60 to match the Updated_By column in Name. Everything seemed OK. TS indicated that they could not duplicate the problem, and indeed I could not either. I changed it back to 15 and watched the event logs for new errors. They appeared Thursday this week, so I connected back to the database and changed the length back to 60 and saved and re-published the object. It errored out the first two times but I got it to publish finally. After I got it published, desktop users started getting portfolio shutdown errors - odbc timouts. I rebooted the server. Upon rebooting I have not been able to log on to the casual view, public site (WCM) and in the desktop, I can connect to the Customers tab, AR, Billing, Events, Expo, etc, but not home, System Setup or Tools. I get the error posted below. When I look at the vBoCsContact view, I notice the UpdatedBy column is missing in the view. I cannot get back in to the BO Designer to edit the BO and try to republish. Editing the view directly does not help. Is there any other way to get to the BOD? Is there any way to force a rebuild of the CsContact BO? Restoring from backup is a very last resort as the customer has entered numerous event registrations and billing payments during the day prior to the backup. Any help would be very greatly appreciated.
I have a custom iBO design in Business Object Designer. It Compiles successfully, but when I click Publish for Debugging, it fails with no messages or errors. Does anyone know what might be the cause?
When we export a document (IQA query, business object, content, content type, etc.) today, if that document has custom permissions it will not import into a database that didn't already have that content with custom permissions. This comes up in the following scenarios:
Beside all that, we often have to apply the same permissions over and over to multiple items. Having our own predefined security sets would make this a lot simpler. (It would also keep the Access* tables from growing excessively, since each "custom set" is assigned its own key.)
I'm in the process of building an AJAX-y search for edit field in a larger form. The lookup needs to use IQA queries from a particular folder (configured property of my iPart).
I'm hitting a snag in the following part of the code. (code includes "using Asi.Business.Common") The error I'm getting (exception I'm catching) suggests I don't have permission to that folder, but the error message was in the sample code, so I'm not sure that's the real problem.
I've hit a little snag with UD_Tables, and I'm not sure the best way to recover.
I'm in a prototype database for a rather large client (implementation in progress). Early in the design, we added a number of UD tables with the fields they wanted. In addition to the standard business objects (e.g. CsName_Demo), we created a couple of custom ones.
As the prototype evolved, we discovered some of the fields weren't needed anymore. Our normal MO for removing fields (bad habit, I know) is to remove them from Define Tables, then touch all the windows based on those tables, which cleans up the orphaned fields. This time, we got a PK violation on UD_WindowFields. Apparently, iMIS now only deletes rows from UD_WindowFields if they exist in UD_Field. I cleaned up the orphaned fields through SQL and the windows worked OK. That problem is solved, and desktop iMIS is (mostly) happy.
