I'm using the offline support of Kendo dataSource. It's kinda' working, in that I can make changes whilst the dataSource is offline and these are sent to the server when a connection is established.
However, the __state__: "update" property is not removed after posting the changed record to the server. This is resulting in the same update being posted to the server multiple times if the dataSource switches between online/offline modes.
I've tried returning the same data as a confirmation of the successful save operation, and I've also tried returning an empty response (as suggested in the documents).
Any ideas?
Related
Client company just upgraded to 2016 from 2011. I've been testing the plugins to make sure they all still function and I've finally (after much frustration) figured out what is happening, but no idea why or how to resolve this.
I have several plugins and they all function exactly as expected - as long as the updates to the data are not run through the forms.
Let me explain:
I have plugins (Synchronous) that trigger on a change to a field. If the field is changed via a workflow, or some other coded process, everything runs just fine.
But when I update the field on the form it's self. It fails with a very generic error (below).
I support a couple of other clients already on 2016, and I'm not experiencing this same problem. So I'm not even sure where to begin. I've been going crazy here the last couple of days to check the code. But it only happens when updating the field on the form. Every other method of updating the data that I have tested works with no errors.
I also have another issue. When the field is updated (through a test workflow), it runs and updates a child record. The child record then has a workflow that runs to deactivate the record. The workflow says it ran and deactivated the record, but it never deactivates).
Anyway. if ANYONE has ANY idea at all about what could be causing this. I would love to hear it. I'm at my wits end on this.
Thank you in advance.
I've tested the code and had it run successfully, as long as I don't update the field through the form. To test this I created some test workflows that update the data, they successfully run and the plugins fire off with no problems.
EntityReference contact =
(EntityReference)preImageEntity.Attributes["ipmahr_contact"];
QueryExpression cn = new QueryExpression("ipmahr_recertification");
cn.ColumnSet = new ColumnSet("ipmahr_contact", "statecode");
cn.Criteria.AddCondition("ipmahr_contact", ConditionOperator.Equal,
contact.Id);
cn.Criteria.AddCondition("statecode", ConditionOperator.Equal, 0);
EntityCollection results1 = server.RetrieveMultiple(cn);
if (results1.Entities.Count > 0)
foreach (Entity a in results1.Entities)
{
a.Attributes["ipmahr_deactivaterecertificationrecord"] = true;
server.Update(a);
}
The code is pretty straightforward in most cases, and works fine as long as things aren't updated on the form.
Here is the error: Exception: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: System.ServiceModel.CommunicationObjectFaultedException: #595EB751 (Fault Detail is equal to Microsoft.Xrm.Sdk.OrganizationServiceFault)., Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af Exiting Recertifications.Main.DeactivateUsedRecertificationsonEndDateChange.Execute(), Correlation Id: fd1a79ca-c846-407b-b578-ac9207d6dd0e, Initiating User: 274d55dc-3f4d-e811-b30f-0050569142af
New information. I have found that not all the plugins I've written have an issue on this server. This is good. But I also found that there is a commonality on those plugins that do fail.
Any plugin using a Query Expression fails with the generic error. Adding robust error checking didn't show anything (once error checking was added, it just didn't run anything, and didn't produce any errors in the logs). Trace logs didn't show anything significant either.
So now I'm wondering if there is something in the way the Query Expression is formatted, or if there is an issue with the SQL. I mention SQL because I found this morning that if I create fields too fast, I get a generic SQL error. Wait a minute and I can create new fields without a problem.
I think it likely that this plugin is not actually failing based on the error you are receiving and the fact that it happens conditionally. More likely, your server.Update(a); call is resulting in a failure within a secondary plugin or workflow action triggered by update of the Recertification record.
- Comment out that line and verify that the plugin works
- See if you can reproduce a failure by directly updating that field on the Recertification record
- Review plugin/workflows running against the Recertification entity
Most likely this has one of the following root causes:
- A security issue based on different executing users between the form update or workflow update
- Other tangential fields are being updated by one or the other of those two methods which subsequently cause different behavior in a secondary plugin/workflow
I just started to use JMeter with the tutorial (for a sample website), which returns clear response data.
But, when I started to use in one of my projects, I saw the response was encrypted in View results in tree.
So can anyone provide solution for it? This was the response i was getting
I doubt you haven't check marked 'Use this proxy server for all protocols' while creating manual proxy configuration. By checking/ ticking that check box it will allow you to record the scenarios and also it gives you a proper response.
and I also doubt that you are getting proper server name. By doing the above step it will solve your problem
I have a strange issue with a Laravel 5.1 application.
Intermittently, it’s dropping session data. I’m detected this by writing some middleware that writes the contents of the session for that request to the log file. Although the session ID (Session::getId()) doesn’t change, the value of _token in the session data retrieved with Session::all() does.
As I say, this happens intermittently. I can refresh the same URL multiple times, and then randomly on one refresh the session data’s gone, and the _token value’s different from the previous requests.
What would cause this? I’ve also noticed the flash object isn’t in the “dropped” session data.
Below is a snippet of the log. You can see the content of the session_data key randomly changes “shape” in the last two lines, but the session ID remains constant.
Also, not sure if it’s pertinent, but I have DebugBar enabled.
UPDATE: Through debugging, I’ve found that on some page loads the session is completely empty, as in, no _token (hence a new one getting generated). Nothing.
If you're using the file driver, you could run into race conditions on concurrent requests. The file then gets truncated, Laravel can't read it, so it refreshes the session. Race conditions can also lead to a symptom where something you're putting to the session just doesn't get put. This tends to be random, so it's very hard to debug. According to the Laravel team, this is a known limitation of the file driver and it does not appear to be getting fixed, so I would suggest using a different driver. This would fix your issue of random session refreshes, but it still introduces a possibility of making a change to the session that doesn't get added. As far as I know, at this point with Laravel 5.1, you'll have to manage that yourself.
Somehow your session data is too long and being truncated. If you're using the database driver (haven't tested other drivers), and you try to save session data that's longer than the field length, then subsequent requests won't be able to pull from this session, and you'll wind up with a new session. If this issue is happening randomly with very short session data, then it's probably the cause listed above.
If you use Linux, Try using Redis (http://redis.io) as session / cache manager in laravel. I had some issues in the past with text / cookies and laravel in some servers. When I instaled Redis I had no problems anymore.
More info: https://laravel.com/docs/5.1/redis
Using a different driver like memcached did not solve the problem for me.
Here is a package that implements session locking which works and very simple to incorporate in your projects.
https://github.com/rairlie/laravel-locking-session
A web site I have published is generating the error stated below when a valid user submits form content to be stored in the database:
Forbidden
You don't have permission to access /index.php/user/add on this server.
Additionally, a 404 Not Found error was encountered while trying to use an
ErrorDocument to handle the request.
This is a private web site. All users have to log-in. Some users can add content. Using CI sessions there is an added field of edit, with a value of 0 or 1 retrieved from the user's record in the user table, copied to the user_data session array at the time of log-in. The variable $this->session->userdata('edit') is used for if statements in the controller and views. Value of 1, user will see links that will bring up views (forms) to edit or add content.
This is a snippet for how I am using the variable to set menu items:
<?php if ($this->session->userdata('edit') == 1) { ?>
<li>Add</li>
<?php }; ?>
This is the basic structure for the processing of form data. This function is in the controller file user.php:
function add(){
if ($this->session->userdata('logged_in') ){
//runs form validation
if ( $this->form_validation->run() == FALSE ) {
//if false, redisplays the form and data with failed fields highlghted
}//if
if ($this->form_validation->run() == TRUE) {
//processes the data and stores in the database
}//form validation run
} else {
redirect ("user/login");
} //if...else
}//add
Examining the database after one of these Forbidden errors, no data is inserting. A redisplayed form due to validation error(s) is not happening either. These factors lead me to believe this is a server problem more than a CodeIgniter issue. If you look at this link it shows a screen shot of the error received in the browser (either Firefox or Chrome, other browsers not in use yet), it is not the usual CodeIgniter appearance for an error generated from a mistake in CI code.
The add/edit content forms are working well. As stated above, the error occurs at time of form submission. As well, it is only happening on the hosting company's server. I have checked the permissions of user.php and they are 644 like the rest of the files.
What are possible fixes? If it is a server issue, what do I look for or ask my hosting company to look at? If it is a CI sessions issue, in the documentation CodeIgniter states it uses a system different from $_SESSION super global. Is it wise to copy the user data to that array and have the code look up the data from that variable array? Or do I create a distinct array and save the keys there?
Revision and Solution
I retested the connection to the database associated with this project. I could connect. Taking things a next step, I could select records but not insert. I performed those tests with raw, simple statements.
Examining privileges for this user and the database, I discovered that while All Privileges was checked, none of the individual privileges was checked. (See this screen shot.)
I ignored the All Privileges check-box and manually checked each of the other boxes. Conducting small tests like the ones outlined above and then interacting with the form on the site, I am getting results I expect.
Things I don't understand:
How can All Privileges be checked and none of the other check-boxes checked?
I have gone back and tried to check All Privileges and then uncheck the others individually. It's not possible. From interacting with Panelbox on this host often to set-up users and associate them with a database, I know it is not usual for the state I found described above.
Programmatically, since there is only one user and set of privileges associated with a CodeIgniter site, how was the admin for this site able to insert 5 records in the database before a Forbidden error started being returned from the server?
I did not outline it when I first posted this thread, but the Forbidden error did not happen right away with uploading and running the site from the server. Since the admin was able to submit five completed forms perfectly before starting to receive errors, I presumed it was a Sessions problem. This contention was also arrived at because sometimes deleting the cookie and then logging in, I or the admin was able to submit a form and the data was inserted in the database.
Thanks for taking the time to read this.
Test user privileges associated with a database often. Sometimes things change.
I want to display the output of an SSRS report in an IFrame of another application. I set the source to something like this:
http://SERVERNAME.domain.com/ReportServer?%2fTBI_MSCRM%2fCustomReports%2f%7bdafdbed0-1e96-e211-a5da-001d0967e0fc%7d&rs:Command=Render&rc:Toolbar=false
The issue I am running into is that the output of the report seems to be cached for the session.
If there is a timestamp on the report that does not get updated when the page is refreshed. To see the updated data, you have to close out all browser and reopen the page. In SSRS, snapshots are not turned on, there is no cache refresh plan as the "Do not cache temporary copies of this report" option is selected.
I have take the URL out of the IFrame and run it in isolation and I get the same results, so it isn't the IFrame causing the problem. What I need is this report to refresh every time the URL is accessed.
Any ideas are much appreciated.
You can force the report server to get a new report in every request by clearing the session.
Just add the following to the URL rs:ClearSession=true
It would be implemented in your URL like that:
http://SERVERNAME.domain.com/ReportServer?%2fTBI_MSCRM%2fCustomReports%2f%7bdafdbed0-1e96-
e211-a5da-001d0967e0fc%7d&rs:Command=Render
&rs:ClearSession=true&rc:Toolbar=false
Clear session:
A value of true directs the report server to remove a report from the
report session. All report instances associated with an authenticated
user are removed from the report session. (A report instance is
defined as the same report run multiple times with different report
parameter values.) The default value is false.
for more information look here