I have installed ISIM 6.0 with a fix pack 6. After installing the FixPack i was able to view the request of any activity performed in ISIM, but now View All Request tab doesn't show list of requests however the transactions are going through fine. Please suggest ?
That usually means that ISIM web app cannot read the requests from the database.
I would enable DEBUG_MAX level in enRoleLogging.properties
file in order to see the exact request made to the database and try to perform the same SQL query manually.
I believe the component needed is
logger.trace.com.ibm.itim.util.level
But you can try setting the level to DEBUG_MAX for all
Then check your trace.log file(s). The location depends on your installation, more details can be found here :https://www-01.ibm.com/support/knowledgecenter/mobile/#!/SSRMWJ_6.0.0/com.ibm.isim.doc_6.0/trouble/cpt/cpt_ic_trouble_itimop_logs.htm
Also check the log files of your isim DB.
Hint: The only time I have come across this exact issue was after an upgrade where the tenant got changed from dc=com to DC=COM. It's a common misconception that the tenant is case-insensitive as we tend to associate this to the LDAP, but it affects SQL queries also (and those are case-sensitive).
ilektrojohn's answer should help you but anyways I have faced this couple of times in earlier stage and hence posting it. Usually its a slight mistake, and we forget to update the Time Interval or Request Type fields. Set them to wider range like this week or this month. Also expand the More search criteria and remove any added filters that might be restricting the search results.
Related
I am using GEOIP plugin in my laravel system. All things are correctly working but response time of GEOIP is very more. I want to reduec it.
I tried to fetch simple IP address but it is not worked , because i need to do country validation also.
use \Torann\GeoIP\Facades\GeoIP;
$respondentLocation = GeoIP::getLocation();
I just need quick response nothing else.
Thank you in advance.
I'm not familiar with that particular library but I'm assuming its looking up remote data (hence the speed issues). If so, there isn't a lot you can do outside of caching records, and possibly pre-fetching data (if your scenario allows for that).
Looking at their docs, it appears they do have caching mechanisms in place: http://lyften.com/projects/laravel-geoip/doc/commands.html
I have a weird issue in an organization i have recently taken over, and briefly what it is, is that no users can do advanced find on any custom entities, and on most of the system entities. The entities are simply not there to be selected for advanced find.
Issue was first reported as, no user having permissions to run reports. After which i have thoroughly checked the reporting services permissions, execution service accounts, etc. And all of them seems to be configured fine.
After this i have noticed that when i try to do an advanced find, i do not see any of the custom or system entities. In the advanced find, only some system ones. Now, when accessing through the sitemap, these custom and system entities are accessible and you can do things like edits of fields and export to excel. But from advanced find nothing.
I have considered this to be a security roles issue, although I have System Admin and System Customizer roles, and the user must not have any permissions on an entity so they don't appear in the advanced find, but still the entities are not in the advanced find. I have also tried exporting all roles from a working organization to the one with the issue. Nothing changes.
Another issue with this is that user cannot do Bulk Deletion, as advanced find queries are used there as well.
Next thing that popped in my mind to check is the CAL user setting. So i disabled all users in the system, and left only mine with access mode READ-WRITE, License Mode Professional. Again, nothing.
Additional Information 1:
I transferred over the problematic organization to a new Server, same thing. This led me thinking that repair would not do much, as it is organization related, and not server related. I have also installed SP1 on the server, which passed fine, but issue remained. There is another organization on the same server, with the same solution/s installed which doesn't have the problem. So it is organization specific.
Does anyone have any suggestions how someone could have messed this up in a potentially unsupported way, as this unsupported is the only thing that comes to mind next?
Yes, like almost every time you post a question on Stack Overflow, you suddenly get much more creative and get additional ideas on how to troubleshoot and approach your problem.
Since i checked the customization.xml file for any settings containing 'advancedfind' and didn't find any there, i tried searching in the database.
I did a sql query searching all columns, for their names, in the CRM organization database and found out the IsValidForAdvancedFind flag in the Entity and Relationship Metadata Tables.
For all entities not appearing in Advanced find, this was set to 0, so when you set this flag for an entity and its relationship to '1', the entity appears in the advanced find.
Now, there is an extra problem I encountered here, is that for most of the records in the Entity and Relationship tables, for the same entity, relationship name, there are two rows for some entities and relationships. At the moment this is still under investigation.
Update/Edit 2
The extra problem encountered was confirmed that both of the records from an entity or relationship in a the two tables, reflected the same value in the
IsValidForAdvancedFind flag in both rows for each entity or relationship. The extra row had most probably appeared after the update was installed. So setting the flag to 1 in both rows didn't cause a problem.
Any one that might be looking at this resolution, please make a back up of your database before proceeding with this fix, and do extensive testing before doing it on production.
End Update/Edit 2
The FUN thing in all this, is that this modification directly in the DB, an UNSUPPORTED one, was done by a Microsoft Partner. Seems passing certificates to become a partner, doesn't fill in some blanks on how to customize Dynamics. Anyway...
We're going to migrate our application from eXist-db 1.4.1 to ~2.2 (probably RC2).
I`m wondering if anybody already did such a migration and what impediments they met?
I already found some documentation about this on official website and tried to Google, but didn't find much. For now I know that there were significant changes in the security model and some APIs are also changed. But still I want to know if somebody investigated further or maybe can share success story.
The main difference between 1.4.1 and 2.1/2.2 is that stored XQueries now need the executable flag to be set. You can fix your permissions automatically using a query as described in the documentation.
It is also possible that some of your existing queries report errors on 2.1/2.2, which they did not before. In nearly all cases this happens because 1.4 was less strict about the XQuery specification and processed expressions which should not be allowed (the standard as well as the implementation evolved). Also, the query engine may now do additional checks to prevent potential issues. Usually the error messages by the compiler should directly lead to the code you have to fix. This may cost a few minutes, but it's worth the effort. Apart from this, no particular migration issues have been reported.
Running Magento Community 1.6.1 on Apache, MySQL.
Hi, I have a huge problem with visitors getting locked out from our site by receiving empty response from server. Any user that has anything in the cart when any product is updated (actually just pressing save is enough), will get locked out by receiving empty_response from the web server.
Users gain access again if they remove their session cookie, and/or we clear the sessions folder in /var/, but until then all they get is empty_response from the web server.
Rolling back the database to one a few days older than the first symptoms kills the problem, without having to replace any files.
No logs or exceptions are produced.
It took a while to cause the problem, and even a bit longer to find the cause, so rolling back to a database backup from before the problem is not an option.
Have read a lot about cookie lifetimes, etc, but nothing of that has been related to this. Furthermore - being able to verify with a functional database allowed me to copy the settings (actually copying the content of core_config_data) from the functional database to a copy of the current live database, for more test. Results were the same…
So, ending up here… would be extremely thankful for any tips, hints or directions that put me on the right track!
Thanks for reading my post, and many thanks in advance for spending your time reflecting over this issue
you should try
database repair tool
clear all logs in database
re-save customer groups
inspect cookie settings with fiddler or any other similar tool
verify that your server clock is correct
enable error messages
inspect server error logs to see if there is any logs related to this
My Joomla! site loads very slowly and sometimes return an error which is:
Fatal error: Maximum execution time of 30 seconds exceeded in D:\Hosting\6926666\html\libraries\joomla\environment\request.php on line 11
Note that the D:\Hosting\6926666\html\libraries\joomla\environment\request.php on line 11
alayws changes (not the same path).
Hint: In local my site working very good, the problem happened when the site and the database are on the server, or the database is only on the server.
My site is Joomla! 1.6 and my host server is godaddy.com
I changed to another template and the website sped up considerably. I then did some investigating and found the index.php of the template has been HACKED and there was EVAL() and BASE 64() code in there! As soon as I put in a "clean" version of the PHP, the website was back to normal!
I agree with Jav_Rock : godaddy is not "compatible" with Joomla.
So, to solve your problem, you should find another hosting provider!
Are you using any third-party extensions? If so, how many? The more you use, the more likely it is that one of them has introduced an 'issue'.
I'd like to suggest that you review the code and database structure associated with each extension to determine where there might be a problem. I'm currently doing this with a fairly simple site that is using a LOT of extensions (so many that it breaks the admin UI). Some of them are terribly written - e.g. making many database lookups when 1 is required, writing to the database with every single request, storing several values in a single column, etc.
However, you say you're a 'beginner', so I think your best bet is either:
Get someone who is not a beginner to do the above review for you
Experiment by enabling/disabling each extension in turn to determine which are problematic. That's not very scientific, but might get you somewhere.
If you can, try enabling debug (you can do that via the Global Configuration). This will show you - amongst other things - how many database queries are required to generate your page. I can't give you an absolute figure for what is 'good' or not, suffice it to say that fewer is better! So, for example, if you identify a low-priority extension whose removal saves you 25% of the total, you might well decide to disable that module - and, possibly, look for an alternative. As a guide, the site I'm working on originally made 500-600 queries for the home page. In my opinion that is far, FAR too many.
for:
Fatal error: Maximum execution time of 30 seconds exceeded
first create a php.ini file and place the code only 'max_execution_time=120' means execution time is 120 Sec. or 2 Minute. or modify according to you..
and put that file into you joomla administrator folder.
Or you can directly edit the php.ini if you have access on it.
also enable cache for the required modules.