08-14-2017 03:57 PM
Customer using Act! Premium V18.104.22.168 update 2. I made some changes to the opportunity module to suit the customer and while testing products were being entered in correctly.
After I had finished testing, I had an issue where I was no longer add products. I found that the issue was the Quantity field was causing the issue. I would need to enter a value in before the product would save. So I decided to add in a 1 as a default value save and test and still same issue check again the value I had entered was gone.
Tried again but a value will not stick, run check/repairs on the database still the same issue.
So I tested on my local with a new blank database. I can see that by default there is a 1 in the Default Value field, so in the customers database somehow I lost this value when adding fields and changing processes.
I then try to change the 1 to 5 in my new blank database with no records or any custom fields. and it has the same issue and reverted back to 1.
I was testing using Act! Premium Version 22.214.171.124, Update 3 from actdiag the database is version 126.96.36.199.
Can I change this setting directly in the database safely? For the moment the workaround is you need to enter a value manually but not idea I wanted this to have a default value so I could hide the field.
08-15-2017 07:58 AM
There should always be the default value of 1 for the quantity but this cannot be changed for the 'Add/Edit Product menu'
I would like to know what changes you have made to Opportunity's as I have seen in the past where this issues can be caused by changing system fields.
08-16-2017 09:17 AM
This is the 3rd item I have read or been involved with trying to help recently where changing system fields has broken ACT. Can I suggest that either system fields are locked down to stop them being edited or a warning comes up - Changing this system field may damage your database or similar as most of these are non-recoverable.
Please pass on to design team, Thanks
08-16-2017 09:27 PM
ok this is what I did in this order.
1. delete all existing opportunity.
2. remove all existing Process.
3. create a new process and add new stage
4. Create a new field in field in the product table. It was a Decimal field with a dropdown list.
5. then I tested and none of the products were being added to the opportunity.
6 at this stage I was not sure why, I did not even think about the quantity field.
7. I then did a check/repair. I then noticed that the field I added disappeared.
8. At this stage I realised that the quantity field was missing the default value, added in and did not stick.
08-17-2017 07:24 AM
@ch1p - While some system fields (normally ones that integrate with other parts of the application) will cause issues with the database. We do have defects logged for some that we know about and would prefer to fix and allow customisation of these fields, in some cases they can be hard to replicate and are unable to put a fix in place at this time. While the idea of a blanket restriction on editing system fields would prevent damage to the database I am unsure if it would require a redesign of how these fields work.
@Damon_T It would appear that you have not made any changes to the system fields in Opportunity's as I expected. I would like to know if the Check/Repair went through without error? It maybe that there was damage in the structure before this issue occurred.
Before proceeding I would highly recommend backing up your database and have included an article if needed.
it maybe required to create a new database, although I would prefer to avoid this.
Can you try running the check and repair once again and after preforming rebuilds from Actdiag you can find this application via 'CTRL + R > Type: Actdiag > Ok the disclaimer > Databases > Database Details List > ensure your database has the ► Icon > Actions > Rebuilds' from here please Rebuild Act! Metadata and Rebuild OLE/DB v2.0 Report Objects.
If the issue continues a Reschema maybe required to try and put the fields back to default, or an empty copy of the database can be created and test if the issue exists in the copy.
08-24-2017 03:40 PM
Hi @Dan Horn
I created a blank copy of the database and can see the same issue. working on this database locally I then performed the check/repair in actdiag.
I did get this error when running the "Repair Database" option
I clicked OK and then got this prompt
I performed this and it came back ok.
Then I ran the "Repair Database" option again and got the same error again. Tried this like 3 or 4 times same result. I then followed the manual schema update instructions and tested after doing this still the same issue.
I am really hoping I don't have to create a new database, they have a lot of custom fields. I can get access to the SQL db directly, I've had a look around but not sure where the default option is to set in the database.
Maybe database repair could look at the blank copy of the database to see what is wrong with it? Or if we have a SQL script that might be able to add the default option back in.
08-25-2017 08:02 AM
There is an issue when repairing via Actdiag it will throw this error for repair database I would recommend running the repair via Tools > Database Maintenance > Repair Database. However I would not expect this to fix your issue.
If you create an Empty copy of your database it will be empty but will still have any custom fields that you have created if the issue does not exist in the empty copy. it may be an option to import your data to this new database.
08-27-2017 03:25 PM
The copy I was testing with is an empty copy of the database. The issue is still present in the empty copy. I created an empty copy so I could work on the database locally for testing.
Any other ideas?
08-29-2017 03:22 AM
Sadly if the structure of the database is the problem we are quite limited in the options.
It could go to Database Repair Services to see what can be done with the database information can be found below:
The other option would be to create a new database and create the fields / users manually then import the data from the damaged database (I would recommend backing up the database after fields have been created.)