Alright, I am thankful for Sugar and will do my best to contribute where I can.
Running the new 4.5 RC 1 using a SQL DB username & database name other than the
std sugarcrm. (I am running multiple different instances of Sugar; as in
completely different/independant installation of sugar and with its own
corresponding db).
Symptom & Problem: When working with custom fields, data entered isnt' saved;
custom field names & properties are not actually added to the sql db.
After having created (in Sugar) the custom fields
In Studio if you click on the 'Rebuild Fields' shortcut, it will create an
output similar to this below (cut & paste of my sugarcrm output)
Note: I'have spent some time searching and reading numerous threads on Sugar
Forums and didn't come across one post that described my particular problem,
cause, or the solution; however, I'm sure that others experience this as well.
I didn't read every last post on the forums before I just got to diagnosing and
resolving it on my own, and thus hopefully this post isn't redundant.
-------------------------------------
SIMULATION MODE - NO CHANGES WILL BE MADE EXCEPT CLEARING CACHE
Scanning Leads
22 field(s) missing from leads_cstm
Adding Column spousesfullname_c to leads_cstm
Done
Execute non-simulation mode
-----------------------------------
And you will then want to click on 'Execute non-simulation' mode followed by
clicking on 'Repair Custom Fields' again. If the same problem(s) are displayed
and thus 'repairing' doesn't apparently resolve it, then continue reading.
Hopefully you have phpMyAdmin installed on your system, if not, install it
before doing anything else as it is invaluable!
You can find it or more info on
it at this link: http://www.phpmyadmin.net/home_page/index.php
I took notice that mycustom fields had NOT been added to the db, thus the crux
of my problems.. The necessary fields didn't exist in the sql db.
I spent a good amount of time 'screwing around' doing various testing &
diagnosing (which included manually creating the fields) before finally enabling
logging and perusing the logs.
The logs showed that sugar was trying to create the fields with a type of
'varchar2' and this detail caught my attention thanks to my previous time spent
on screwing around. When I created a couple of the fields manually via
phpMyAdmin I didn't recall varchar2 as one of the type options and upon
verifying that, I confirmed it wasn't.
Thus I thought I found my problem.
My fix? (and mind you I was doing all of this from the console {kvm switch} via
X rather than from shell)
I searched the sugar root directory recursively (and all sub-directories) for
any file(s) containing the text string 'varchar2'.
The results were only 5 files.
I then made a backup copy of each of those files by adding the extension .org to
the copy.
Now it was time to do some investigation & likely editing.
Getting to the bottom line, every instance of 'varchar2' was changed to
'varchar' (which were only a handful of such instances).
I then returned to sugar and ran the 'rebuild/repair custom fields' routine.
Once it was completed I then checked the actual db to see if the fields had been
added, and yes they were there!
I then ran the 'rebuild/repair custom fields' routine again to see if it would
still say there was a problem, and this time around it returned no errors or
problems.
Now I've taken the moment to write this post as a little break from working and
have yet to check or verify the storing & or retrieval of actual data to those
fields. Eitherway, data storage/retrieval working or not doesn't matter because
this issue ultimately was pertaining to the creation or modification of the
actual database field(s) and/or the properties for that field.
Chris,


LinkBack URL
About LinkBacks



Reply With Quote
Bookmarks