I have made an app that collects data from my robotics competition and then sends it to a fusion table. It has worked before this and was working last time it was tested one week ago now when I try to send the data I get this
Transmission Error400 Bad
Request Required:X-Goog-
Encode-Respnse-If-
ExecutableBad transmission
this is the error as formatted that is happening in the app. the only Idea I have is that it may be a security issue because it is a 400 error but I cannot even begin to know where to start the competition is tomorrow and the copies from previously do not work either I need help quickly other info is that is was made using app inventor 2
Related
I have a custom database application using Access 2016 (MS365 account) with backend data on a file server and a local front end with many VBA-driven forms. All has been working sweetly for several years, until this morning when myself and the all other users started to receive "No Current Record" errors on certain forms (not all).
I assumed it was a rogue record or corrupt DB so I went back to the previous day's backup data but the same problem occurred. No front-end code changes have been done recently, and in any case different users are using slightly different versions of the FE system, yet all suffer the problem, so it's not specific to particular VBA.
I went back many weeks of full data backups - all throw the same error now, although had worked fine at the time of course.
I've repaired and compacted, uncompiled and so on, but it won't clear the error.
I have a strange hunch it might relate to an Office update, as I believe the problem was not present on a machine that happened to be disconnected from the internet, but this is only 80% certain.
Has anyone ever had problems arising after updates? I cannot think of anything that has changed in the data or the front end so I'm struggling to understand what else it can be.
There have been multiple reports now that this may be a bug caused by Patch Tuesday updates. Refer to https://www.devhut.net/latest-office-update-version-2204-source-of-new-bugs/
I've been working on a project involving the Watson Retrieve and Rank service and it was acting normally until now. I managed to upload a number of documents and created roughly 50 questions to start off. Normally, I was able to upload the questions just fine, but now I keep getting an error saying "Questions upload Upload failed".
I have attempted to use different browsers and going into incognito mode, yet nothing seems to solve the issue. I either get the error or the upload questions animation plays endlessly.
This is what it looks like as I try to upload the questions
If anyone could give some insight on how to approach this problem, it would be great.
Can you provide the entire error log?
Are you sure the solr cluster and collection are created correctly? The Standard Plan for this service only allow 7 rankers in the free plan.
You can try it with a new instance of the service.
Are you sure your training data meet the requirements?
Training data requirements:
https://www.ibm.com/watson/developercloud/doc/retrieve-rank/training_data.html
Retrieve and Rank wasn't working correctly on Wednesday and Thursday. But today its up and running properly.
I am having issues with Kimono Labs. Every scrape I run will run indefinitely without throwing an error or completing. Occasionally, the scrapes will randomly start working days in the future without any changes on my behalf - only to fail a few days later. I love Kimono because it is so easy to integrate with Google Sheets for friends to alter the data, but this has become problematic. There doesn't seems to be any related help in the Kimono help data for an issue such as this.
One of my scrapes is not behind a paywall and the other is. One is set to run daily and the one behind the paywall is set to run hourly.
What steps can I take to troubleshoot this error and get the ball rolling again?
I had a very simple API doing the exact same thing for weeks!
I'm only using a free account so I didn't have any support but I ended up sending a bug report at https://www.kimonolabs.com/support .
Strangely enough, the very next day, the API started working normally again (and has ever since). I assume they looked into it and fixed whatever was stopping my crawl from completing.
NOTE: This is more of a "philosophical" question than a technical one.
So, I'm writing an iPad app which syncs its data to a backend which I also wrote. The sync works well, on a good network like the one at my apartment.
But in a slow or otherwise mediocre network like the public one in a Starbucks or my office it has a tendency to error out. In my testing, when it fails (albeit, infrequently) on these mediocre networks it's a timeout or "could not connect to the server" scenario, and the second attempt has consistently succeeded, resulting in a successful sync.
So my question is about how or whether to report these errors to the user. Right now I quietly report all errors to the user ( using an unobtrusive error mark, not a modal dialog ), but it's annoying in these scenarios because the next sync (has so far) always succeeded.
For some context: My app syncs in the background, continuously, as local changes are spotted and pushed to the server and as a long-polling background thread watches for changes on the server and pulls them downstream to the app.
My thought is that when I sync, I should try (for example) 3 times, breaking out on the first successful attempt. Only if all three attempts fail should I report an error to the user.
Is this a reasonable idea? Or is this a terrible idea?
Thanks,
I'm designing a .net interface for sending and receiving a HL7 message and noticed on this forum theres a few people with this experience.
My question is.... Would anyone be able to share their experience on how long it could take to get a message response back from a hospital HL7 server. (Particularly when requesting patient demographics) - seconds / minutes / Hours?
My dilemma is do I design my application to make the user wait for the message to come back.
(Sorry if this is a little off topic, it’s still kinda programming related? – I searched the web for HL7 forums but got stuck so again if anyone knows of any please let me know )
cheers,
Jason
In my experience, you should receive an ACK or NAK back within a few seconds. The receiving application shouldn't do something like making you wait while it performs operations on the message. We have timeouts set to 30 seconds, and we almost never wait that long for a response.
This is quite dependent on the kind of HL7 message sent, typically messages like ADT's are sent as essentially updates to the server, and are acknowledged almost immediately if the hospital system is behaving well. This will result in a protocol level acknowledgement, which indicates that the peer has received the message but not necessarily processed it yet.
Typically, most systems will employ a broker or message queue in their integration engines so you get your ack almost immediately.
Other messages like lab request messages may actually send another non-ack message back which contains the information requested. These requests can take longer.
You can check with the peer you're communicating with to see what integration engine they are using, and if a queue sits on that end which would help ensure the response times are short.
In the HL7 integration tool I work on, we use queues for inbound data so we can responde immediately. And for our outbound connections, 10s timeouts are default, and seem to work fine for most of our customers.
When sending a Query type event in HL7, it could take a number of seconds to get the proper response back. You also need to code for the possibility that you will never get a response back, and the possibility that connected systems "don't do" queries.
Most HL7 nets that I have worked on, assume that all interested systems are listening for demographic updates at all times. Usually, receiving systems process these updates into a patient database that documents both the Person and Encounter (Stay) information on the fly.
In my location, my system usually gets about 10-20 thousand messages a day, most of which are patient demographic updates.
It depends if the response is generated automatically by a system or if the response is generated after an user does something on the system. For an automatic response it might take less than a second, depending of course on the processing that is done by the system and the current work load of that system. If the system is not too busy and processing is just a couple of queries and verification of some conditions, considering network delays, response time should be a few seconds or less.