Thank you but that's the issue. I did connect the camera but the computer is not detecting it. Do you think it's the USB connection? I understand there can be a conflict between 2.0 and 3.0 but I am not sure in this case.
Thank you John! I do feel a bit foolish that I did not look there before posting! I was previously accustomed to connecting my camera with my old Mac and the Canon software would simply open immediately. Learning curve....
This happens every time Apple updates the OS. The version that was "current" when Canon released their camera software was Sierra so you find it in the Sierra section. That software still runs on High Sierra (every Canon app that I want to run on my High Sierra macs works without issue.)
Yeah, I was having a major panic attack for no reason I guess! Next, organize the 3000+ files I just uploaded... ugh, they all uploaded individually and not by dated folders. Once again, need to start over with everything. Getting them copied to an external drive then the cloud, then just removing them off here asap.
To avoid these issues, you can have a stable version that your users have while you work on the latest version. Once your new version is ready, you can make it the stable version and share it with your users. More at Maintaining a Stable App Version AppSheet Help Center
If the xml file exists, it uses the directory to look for the runtime files. Not sure why anyone would want to do that as disk is cheap (free) and makes way more sense to just copy the runtimes in the same folder as the exe.
I am experiencing the same issue just running a vanilla build done via orcascr190.exe. All the updated DLLs are in my PATH and I even tried a Start In (shortcut) pointing to C:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime 19.2.0.2670.
As Mike said, when there is no XML file with the same name of your application executable under the directory where the EXE resides, in the meantime, you copy all correct DLLs from the C drive common/Powerbuilder/runtime 19.2.0.2670 folder, your application should be able to run correctly. Unless it is a 32-bit app with non-32-bit runtime files.
I'm at a client and they have an instance of Alteryx server installed. I'm using desktop 11.3 and publish to the server but get an error message. I've looked all over to see if perhaps the Alteryx server edition they have is an earlier version but cant find it.
I'm running into the same issue as Angel, but what I don't get is why in the hell is the module installation (chunk file ?) inserting an entry in the DB_Upgrade table for Version 8.0.0 , as I added the RED module (1045) from the 2013R2 Media (thru Add/Remove Programs - Change).
EDIT: I found out from where this entry came... somehow one of our dozen GP companies had remaining old table entries from the RED module... that what caused the issue. I deleted the PPxxxx tables and than I was able to install for the other companies.
The issue persists because of this company in row 4, but the problem was brought to me after the user reported errors when trying to log in to company in row 1 as well, so I guess something happened during the upgrade to 2013.
The issue isn't with row one in the first db_upgrade results, it is with row 4. If you look at the DUinstall.log file now I bet it says it cannot upgrade from version 8. You will need to delete that line and insert in a new one for that company.
"Database setup has not been completed for Microsoft Dynamics GP. Use Microsoft Dynamics GP Utilities to complete the database setup before starting Microsoft Dynamics GP" and tables for R/ED have been created, but tables for Electronic Reconcile are still missing and I'm still getting:
If the version check table does not exist it will reinstall/reinitialize the module (drop all object and recreate them). However if it does find that table it will insert a record for GP 8 (or 9 depending on when the version check table was introduced for that module) into the db_upgrade table.
I am not sure how this has been working before as when you log into GP it is going to check the DU000020 table and when you log into Utilities the db_upgrade table. If these were added at GP 2013 then you could insert records into these two tables for this company but you need to realize that you have to be 100% sure that these modules are actually on GP 2013 version otherwise you are going to start getting errors in the application.
All of the sudden a client appears be getting this error when trying to start processes. "The Process Model cannot be started. There is no published version". This happened in a test environment. upon inspection of the process model it seems like the PM was missing the latest versions as if someone came in and deleted them and now there were only a few old unpublished versions. A quick solution was to save and published the PMs in the dev environment and deploying them again. However, I don't know what might have caused this problem?
There are some ways you can get into that situation. As you mentioned maybe someone can go and delete the last version which was published. Maybe the last use who published it left the company? Here are multiple ways to prevent this to happen.
Hello!
I realy gave the Parametric stuff a chance. But it turns out to be a real pain in my design process and everything took way longer than it was before.
As an example, before the Parametric stuff it was pretty easy to make an sketch from holes or entire planes, now its nearly impossible without a lot of work, which is Cleary nothing that I like, which was one of the reasons why I swapped to Shapr3d. Everything was pretty easy and now it feels like I want just unsubscribe this bloody hell.
I understand that at the first time parametric modeling can be confusing. What is your problem exactly? Basically if you close the history panel, Shapr3D should work almost exactly the same as before, the biggest difference being that instead of deleting your sketches, you should just hide them.
Well I hate to hear that. I would just rather have the previous version. I dont need a tesla roadster when my golf cart does everything I desire. Maybe at the next Weekly Operations Meeting, yall will approve/allow us to use the other version (pre update).
I can appreciate the advancement of a program for those who may want/need it. I just think this should have been an option, ie the old version (Basic Plan) and the new version (Advanced Plan). Or something therein. You know, offer the Plaid and the golf cart, for an extra $5 a month you can get the new advanced updated version.
The Please reload - message appears much too often. During running prints and days after the last time I installed any sort of update. When I change from firefox on the (linux) desktop to the (osx) laptop I almost expect to see it. But it pops up as well when Octoprint is in just one browser and nothing changed since I strted the print . Well, nothing that I know off.
It's not a show stopper. Behind the semi transparent background I see the the dashboard, the graphs updating, but it's not usable for the text box is seriously in the way. I can (and have to) swallow it and hit reload and wait until the interface rebuilds and finally, after too many seconds, the message is gone and everything else looks like it did before.
"There is a new version of the server active now" - what does that actually tell me, in the midth of a print?
I just wonder what is the use of that event. What sort of bad does it help avoid? What triggers that message and is there a way to tune the triggers sensitivity a bit down? Or give the message a [Later, ok?] - option.
oh, I might add that this is not a new phenomenon, it's been around for a number of versions and no, I cannot say when it all started. I always wanted to post the question but was running octoprint in my local language and now finally came to switch the ui language so I can copy/paste the message...
There's a number of variables that are tracked by the server, and all computed whenever the tab disconnects & reconnects (say, after you put the PC to sleep and came back later). If the client is out of sync with the server, then you have to reload the interface.
This stops you clicking on buttons that send outdated information back to the server, viewing things that may be outdated, or in the case of installing plugins/updates etc. then there are things that simply don't exist anymore. So instead of doing some actions and nothing happening, reload the UI to get everything back in sync. Sometimes the differences are small, and you might not notice them. Some differences can also be introduced by plugins you are using.
I don't feel this addresses the problem. Every time my system (PC or tablet or smartphone) went to sleep or otherwise "disconnected" (ex. on a tablet just switching away from the browser app to another), when coming back you can see that all widgets on the dashboard (yes, also a plugin) get nicely updated, but then you can't get to it because a popup stating the "a new version of the server" was deployed and you need to reload, which depending on the connection (ex. remotely from a smartphone through a proxy) can take way longer than 5s.
Why can the UI not just correctly refresh all data and that way avoid "sending outdated information back"? Having to reload everything - even if the server code did not change - sounds like the dirty work-around which should not be needed if things were programmed correctly ...
Because plugins are able to do things to the UI that are completely outside of the control of OctoPrint (as they happen 100% in plain JS), because that enables them to do a ton of things than I could ever envision. Because even small config changes can cause UI changes, OctoPrint can't know which ones do and some plugins abuse the config for data storage that needs constant updates. If you have a suggestion on how to make this better without crippling plugins and/or become backwards incompatible, the dev discussions are always open.
c80f0f1006