Can any one tell me how to have the records inserted into the database externally be displayed inside the SuiteCRM?
When i do that, i get an error “Error retrieving record. This record may be deleted or you may not be authorized to view it”
Can any one please help me?
SiteCRM database modifications done externally
not 100% sure but you should start with “repair and rebuild” the database in the admin section
it’s either that or clearing the cache folder.
do i need to remove all the data from cache folder?
not sure if it the correct process but what I do is delete the contents of the cache folder(without removing the main folder)
the change the the root and chmod -R 777 /cache
Okay. Thanks for your reply.
But do people do this like have the database updated by another application and use CRM for administration and view the records?
please do not start deleting everything from the cache folder. This is dangerous, especially when data are in it. you can not delete anything that’s in there !!! `
There documents such as e-mail, attachments, documents etc. are stored.
At the present time can be deleted:
Can only partially be deleted:
Can not be deleted: - unless you know exactly what you are doing -
Each record created over the Importer receives an ID when it is imported only directly in the database, then this course is missing.
why do you want to import directly into the database?
RE: SiteCRM database modifications done externally
This may be a problem because my addition appears attached to SQLite. I couldn’t Workbench into it. So, may be next year I’ll push it over to MYSQL. If ever I can Workbench into it, I’ll report back.
We are having a different application accessing the database and creates records. I want these records to be accessed by SuiteCRM which means the database is modified externally. Do you have any solution for that?
@amulyavelpula I think the best way to have an external application create records to be used inside SuiteCRM is using the SuiteCRM webservices. You can invoke the necessary functions (like set_entry, or get_entry_list) to achieve the desired functionality.
One of the projects I am working on at the moment at my day job is customizing SugarCRM. We want to start managing all changes to SugarCRM using subversion, so we need to know which bits should be under version control and which bits should not. During my analysis I came across the ill‐named and infamous cache directory.
SugarCRM’s cache is anything but that. I already knew that uploaded files and e-mails were also stored in the cache directory, but I needed to know exactly what was in the cache so I can make some informed decision on what to put under version control and what bits of a production system should be backed up. I found my answer, after a whole lot of searching, reading the SugarCRM source code and asking around. It turns out that the cache directory contains a hodgepodge of user data files, configuration files and—oh yes, there are some real cache files in there as well.
If there is one thing to take away from this article it’s “Don’t mess with the cache unless you know what you’re doing”. That bears repeating:
“Don’t mess with the cache unless you know what you’re doing”
With that firmly burned into the back of your eyeballs, here’s an overview what the cache directory contains.
This top‐level cache directory contains many subdirectories. All the standard directories are described below. Sometimes Sugar creates even more directories in here, for example when upgrading from one version to the next. Unless explicitly noted below you should never delete any of the files under the cache directory.
This directory stores the blowfish encryption keys that SugarCRM uses to encrypt and decrypt your POP3, SMTP and IMAP passwords. If you remove them, SugarCRM can’t decrypt the passwords anymore and you will need to re‐enter them.
Exports in CSV format are stored here temporarily before you download them. You can safely remove these.
Sugar keeps a list here of all dashlets that you can use. You can safely remove it. Sugar will recreate it automatically when it’s missing.
When you run Sugar’s diagnostic tool, this is where it stores the diagnostics file. You can safely delete these files.
This directory contains caches of all the custom modules and fields in order to speed up Sugar. You can safely delete it. When data is missing from it, Sugar will recreate it automatically. If you use the “Quick Repair and Rebuild” function it will also be cleaned and repaired.
When you users subscribe to RSS feeds in SugarCRM, they will be downloaded to this directory before being displayed to the user. You can safely delete these files. Sugar will re‐download them.
If you have created any web-to-lead capture forums, this is the place where they get stored. If you use these forms directly on your website (for example via an i‐frame) then you cannot delete them. But if you are like me and simply used them to create the correct HTML for your own website then you can safely remove these forms.
This is a very nasty directory because it contains multiple types of data. Do not mess around with it! The first type of data it contains are images that you embed or attach into outgoing mail. These images are cached here before actually being attached to the e‐mail when you hit “Send”. If you are using SugarCE (Community Edition) then you can safely remove these files. If you are a SugarPro or Sugar Enterprise user then you’re out of luck. These editions of SugarCRM come with the Knowledge Base add‐on module. This directory is the permanent storage area of all the files and images you embed and attach to your Knowledge Base documents. You should not delete these! This directory is a prime example of how not to use a cache. Bad developer, no Twinkie for you!
When you import data in csv format, the uploaded files will be stored here. You can safely remove them.
In Sugar 4.0.1 and below, this directory holds the HTML files for the views that you customized with Sugar Studio. In Sugar 4.5.x and up this directory doesn’t seem to be used any more because the custom views are now stored in the custom/ and modules/ directories. So, this directory should be empty, but if you run an old Sugar (4.0.1 or prior) then do not delete the contents of this directory.
This is the directory where SugarCRM stores caches for all of the modules, templates, views, vardefs and more. You can safely remove most of these files, except some directories in the cache/modules/emails directory as listed below. They will be regenerated automatically when they are missing.
Updated: Thanks to spaps for this one. If your users are using their e-mail inside Sugar then the emails cache directory will contain multiple directories with uuid directory names (like 1e1c2480-473f-ee19-16f0-48c63de4bec8). You must not delete these.
When you download a report in PDF format and Sugar cannot stream it directly to your browser, it will store the PDF file in this directory and offer it as a download. They can safely be removed.
This directory contains three subdirectories that hold caches and configuration files for the Smarty templating engine that is used by the new MVC system in Sugar 5.0 and up. For a detailed description of what they are for you can read the Smarty manual. You should not remove these directories.
Smarty is able to cache static HTML version of templates which are stored here. Sugar does not use this functionality so this directory should be empty. If it’s not empty then you can safely clear it.
Here live the configuration files for the Smarty templating engine. It should be empty (as of Sugar 5.1RC), but if a future Sugar update ever installs a file in this directory it should not be deleted because it’s a configuration file.
This directory contains compiled versions of all the Smarty templates. They are similar to the cached templates but they are dynamic PHP code instead of static HTML code. Smarty will automatically regenerate them if you delete them.
This contains all the files that you uploaded or attached to things in Sugar as well as your installed modules and upgrades. The contents of this directory should not be deleted. If you do, you will loose all the e‐mails, attachments and other files that your users added to Sugar!
The pipeline graph and various other graphs that SugarCRM displays are generated from XML files. These XML files are stored here. Sugar will regenerate them so you can safely delete the contents of this directory.
There is one directory that I haven’t quite figured out yet. On the SugarCRM forums a user called SugarDev.net posted a recipe for getting SugarCRM under Subversion control. He manually created the cache/data directory. None of my Sugar installations have that directory and grepping the SugarCRM source code yielded me no results about it either. When I do figure it out I will update this article accordingly.
May be the import has not been done correctly. Do check the “Assigned To” field. Possibly that would not have set in the database, which restricts you from viewing.
Thank you for sharing your research.I had no idea “Cache” was not just a Cache directory
It seems it is not related to cache. Can you verify that record has correct assigned user id and deleted flag to 0. is that record admin can access?
It is good if you can share sql query for record that you are trying to access.
I made a mistake in defining the relationship between the two modules and that created the problem. Thanks for all your support.