I am using Maximo Anywhere 7.5.2 (Work Execution app). I need to select multiple FAILURE CODES instead of selecting Problem, Cause, Remedy.. The failure list should be multiselect.
Maximo doesn't support multiple failure codes (just the hierarchy of failure class->problem->cause->remedy. You can't support it in Anywhere without supporting it in Maximo.
Related
In a BizTalk mapping, I use a scripting functoid from an external assembly. The assembly reference is added. When the mapping is used, however, it causes the following error:
'ScriptNS0:DoSomething()' has failed.
Now, this could mean any number of things that's wrong about this scripting functoid. However, even when a try-catch block is placed around the entirety of the C# code and the catch throws a custom exception, a proper new deploy yields the very same error and not the newly added custom one.
This would suggest that the mapping has been started and that something causes an error as soon as it hits the scripting functoid, but without actually performing even the slightest action within the function. When looking at the XSLT of the map, it seemed perfectly fine. The reference to the external assembly has been checked over and over again (and references of this external assembly as well). Everything looks fine and very much like many other mappings I've seen, yet still the outcome is the error above.
I realise this is a rather vague question, but does anyone have a clue what's going on here?
You'll have to test this out in Visual Studio. A few things to keep in mind:
It's very possible that your actual data is causing an exception (it's an edge or corner case that you're not testing for in your console application).
Throwing exceptions in external assemblies doesn't always translate well in an XSLT map, particularly when you do it on a Port. IIRC it's handled slightly more gracefully in an orchestration.
If you can't reproduce this in Visual Studio testing or a unit test, you should be able to attach the Visual Studio debugger to the appropriate BtsNtSvc.exe or BtsNtSvc64.exe (or w3wp.exe if it's running in IIS/isolated host). Set a breakpoint on the entrance to your custom function, step through, see what's going on. If you're only able to reproduce it in a non-dev environment, see if you can set up remote debugging - but you may be better off enhancing the logging on the functoid in that case and redeploying if possible.
In general, I always try to do the following in custom functoid scripts:
Avoid throwing exceptions - use methods like TryParse rather than Parse, and on failure to parse return an error string or an empty string or the original string (depending on requirements/tolerance of destination system) rather than throwing an exception. If you do throw an exception, it's unlikely to be handled gracefully and unlikely that the exception type or text will make it back to a user/administrator.
Do error logging in these scenarios instead - generally using the Windows Event Log (System.Diagnostics.EventLog.WriteEntry). Make sure to use a properly registered event source, ideally one that matches your application name and is registered by your installation process, but at least one that exists on the computer to avoid throwing another nonsensical exception! This will allow developers/admins faster insight into what's going on next time.
I am trying to record/automate an application developed in Sybase' Powerbuilder. I am currently using HP UFT v12.54.
Using the default recording process, the object spy is only seeing the area on my PB Window, not the specific field/dropdown. In short, I am unable to select a specific object in the window.
Please see the following image:
I am trying to select the Authorized Signatory field, but instead, UFT does not see the specific element, but the field area Customer Data instead. UFT just references the fields in the area by xy axis, not the specific object. Is this the default behaviour?
Additional info:
Application is developed in PowerBuilder v11.5
Any input would be appreciated.
if the first impediment is the modification of the application made in PB, then the next option would be to use a third application that supports applications made in PB. There is the TestComplete application that can do what you need. I leave you some information links.
http://testingbaires.com/testcomplete-automatizacion-de-testing/
https://smartbear.com/product/testcomplete/overview/
https://support.smartbear.com/testcomplete/docs/app-testing/desktop/power-builder/classic.html?q=powerbuilder#supported-powerbuilder-versions
I would personally modify the PB application by creating a module with the necessary battery of tests and running the study window with each and every case and applying an output report based on the needs, I understand that it would not be complicated.
The PowerBuilder's DataWindow control is a special custom-drawn control that cannot be accessed from outside of a PB application. It is internally managed and PB dynamically (re)uses the same windows edittext to get the input for one value at a time, while only drawing the rest of the data without using standard windows controls but a kind of canvas.
This is due to the initial portable design of PB (it used to be available for Solaris, MacOS and some other unices in the past) that implies a virtual machine like for Java (hence the pbvmxxx.dll for PB virtual machine).
I am afraid that from the outside, the only option to pilot a PB application would be to use sendkeys and mouse clicks, provided that the taborders are correct to access sequentially all the DW controls.
This is not the default behavior of UFT with power builder applications, you should either see a PBWindow Object or Proper Powerbuilder objects in the Object Spy.
According to the PAM, UFT 12.54 supports Powerbuilder 11.5+.
Below are the few things you can try
1) Make sure all of the latest patches are installed
2) Try to use record and run settings to open the power builder application. Once Record and run settings are set, click on record button and UFT will open the application. Then stop the recording, open object spy and check if its recognizing the objects after that.
3) Run UFT as admin. UFT needs the same privilege level as the application. So if you're application is running in higher privilege then UFT then UFT will not be able to recognize anything on the application.
If nothing works then you can open a ticket with HP, because powerbuilder 11.5 is supported by UFT 12.5.
I am working on developing oracle forms 6 at my pc work everything goes fine using oracle form builder and oracle database 9i
oracle form builder but when I am working at same project at my home I get the below error message
ora-00600 internal error code arguments:
[17069],[130311952],[],[],[],[],[],[]
I think thats cause I am using on oracle database 11G at my home so if thats true how to solve that issue since I need oracle 11G on my pc home ??
I search and found that this message consist of six arguments which indicate the origin and attributes of the error first argument is the internal error number and the Other arguments are various numbers that may change meanings between different versions of Oracle so please I need expert help
Note: I had noticed that everything goes right and only forms which contains
from dual statement will rise this exception
Thanks
It turns out that you must use SYS.DUAL from within Oracle Forms instead of plain old DUAL, as per here. Quoting:
Possible causes include:
time-outs,
file corruption,
failed data checks in memory, hardware, memory, or I/O messages,
incorrectly restored files
a SELECT FROM DUAL statement in PL/SQL within Oracle Forms (you have to use SELECT FROM SYS.DUAL instead!)
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.