Report on Logical Errors - runtime-error

I recently encountered a logical error in one of our systems and our management wants a report on this. What do we call this kind of report? Also I would like to know if there is any resource available on-line that can help me write this report.
I have already prepared change management, got it approved and made the necessary correction to the application.

i believe, this should be incident management report as well. This error happened unexpectedly and affected the daily operation of the business.
ITIL Templates:
http://wiki.en.it-processmaps.com/index.php/ITIL-Checklists

Related

How can I prevent "GetCallFailed. Failed fetching operations" using Logic Apps Standard

A couple of us are working on (different) Workflows in a Logic App; we are finding that after a couple of hours development work we start getting this error "GetCallFailed. Failed fetching operations"; this occurs when attempting to add a step in the Designer and it can no longer populate the Built-in operations, hence we are completely blocked. We also find that it is no longer possible to manually run a Workflow, which is probably related? Previous experience shows that waiting, perhaps overnight, appears to resolve the problem - at least for an hour or two. Research has suggested Storage or Network problems, but it's hard to see how problems there could account for our case.

Issue tracking with automatically generated issues

In my company we are now looking to start using an issue tracker. So far we've been using our task management system for issue tracking, and now we need something more advanced.
We found out that we have lots (1000s) of small issues that we can automatically generate, and we want to handle them based on a prioritized queue. Such small issues are usually content issues. Sometimes issues are outright errors that come up, and we want to prioritize these based on how critical the error is and how many users encountered it.
Another feature we are looking for is the ability to aggregate issues that are identical, based on some identification string we can generate. We would also like it to be possible to aggregate issues manually - i.e. mark two issues as duplicates in an easy way via the UI.
Finally, we are interested in the issue tracker to have a usable set of tools for managing issues manually - prioritizing, setting owners, generating reports, etc.
My question to you is: what issue tracker would you recommend we use?
If the question is still active, I am a developer # bontq.com. It is an issue tracking system with both web access and Win/Mac desktop apps, SVN, GIT integration, public API, prioritisation and a bunch of other useful features, which you have not mentioned in your question. You can create a free account there and try the system - maybe it is the one you are looking for.
If you will have any questions regarding the system (especially web interface and API) - you can ask me here. I will gladly help you.
PS: this response is not an advertisement - just trying to be helpful.

Reporting Web Application without SQL database?

I have build a Reporting Web Application using ASP.NET and SSRS with SQL DB.
Below is my concern :
Report rendering is slower . I need to make the report faster. Does Crystal Reports or some other things helps me to make report faster? Please suggest
I have heard from the experienced people that SSRS deployment will be more complicated to deploy correctly compared to crystal reports?
Can we build the reporting engine without SQL DB ?
May i know the different technologies to build web based reporting engine which is faster, licensed free, easy maintainence...
Thanks in advance
Ad 1, rendering times. You should investigate the cause for the slow rendering. SSRS is not particularly known for its blazing speed (specially with heavy aggregates and large numbers (hundreds) of pages, but should be fast if you use it just as what it is: a reporting tool. If you have problems, analyze the ExecutionLog2 to check if it's the query, the processing, or the rendering that's giving trouble - and optimize accordingly.
Ad 2, deployment. There are a few issues to pay attention to, but in general you should be fine. In any case your question as it stands is too broad for SO, and fishing for opinions. I recommend you search a bit more, and if you still have a question ask it in chat (subjective, opinions) or on SO (objective, practical questions).
Ad 3, no DB. You can connect a multitude of data sources to a report, including object data sources.
Ad 4 "best". I suggest you remove this subquestion, because it's really a subjective question asking for opinions (this is not recommended, as per the stack overflow FAQ).
Good luck building your reporting solution!
As an answer to 3 => If you use crystal reports for instance, you can construct you own dataset in code and pass the dataset to crystal reports which will do the formatting. This way you can omit the need of an sql db.

Should any PeopleSoft installation require on-going daily DB scripts to resolve "issues"?

I have very little PeopleSoft experience but have been put in a position to support an install. This question could straddles serverfault but is certainly developer oriented.
On a daily basis, we have a PeopleSoft "developer" who writes scripts to fix records/journal entries/approval status etc. To me this screams "bad install" and botched customizations. Is this normal? Is it best practice to have an employee having to write scripts daily just to keep things running?
Note: there is no fraud happening here, he has the full approval of the accounting department when doing this.
It is unlikely that it is the installation. Likely causes:
Bad customization
Missing patches
Bugs in the delivered code
If you only have one admin, though, and you have only one developer, I would be shocked to hear that there is much in the way of custom code.
Back to the question: It is not normal to need to do SQL updates regularly to fix data. Yes, it happens, but not too often. It is also possible that the end users could fix it from the application, but do not for some reason.
Ad-hoc SQL updates can be dangerous and the SQL may change on every request. It is difficult to fully test ad-hoc scripts due to the turnaround they typically require.
I assume these "fixes" are in fact making changes not implemented by the system.
It would be more sensible to either:
Build a custom page to "fix" the entries (or less sensible: modify the delivered pages).
Build and thoroughly test a paramater-driven App Engine to perform the most commonly made changes. It could potentially be run as part of the batch stream.
Watch out on your next upgrade: application tables have had a lot of changes in recent releases.

Is there a problem with ADO.NET DataSets in a load balanced environment?

For the last few months we've had a wierd problem with our website. Once in a while various queries to the database, using ADO.NET DataSets, will throw an error... the most common of which is "Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints."
The data is actually valid though, as without changing anything the error will be intermittent. Further, the "fix" for it is to recycle the app pool on both web servers... so the problem can't be bad data being returned. Once this is done it can run fine for weeks at a time, or break 3 times in one day. There's no consistency to it...
It also seems like newer means of data access, such as Linq 2 SQL, work just fine... though it's hard to tell since the site is using both at the moment. (Working on getting everything over to L2S, but don't have a lot of time to rewrite old components unfortunately...)
So has anyone had anything like this before? Is it something with the load balancing? Maybe something wrong with the servers? (I've forced all connections to each server in turn and experienced the error on both of them.) Could it be something wrong with running in a VM?
Err... ok, so the overall question is: What's causing this and how do I fix it?
Oh, and the website is in .NET 3.5...
Based off of what you've said, I would guess that this is related to the load experienced on the servers at the time of the error.
If you can, set up a staging environment that is load balanced like your production servers are. Then start load testing the app.
Also, make sure you have all the latest service packs / updates applied on your production servers. MS has a tendency to not tell us everything they are fixing. Finally, look on MS connect to see if a hotfix corrects the problem you are talking about.
UPDATE:
Load testing can be as simple or complicated as you can afford. What it should do is run through a sequence of pages that perform standard operations on your site in a repeatable way. You usually want to simulate "think" times between each page load / operation that are in line with expected user behavior.
Then, you execute the test as a certain number of simulataneous users. While the test is executing, you need to record any errors and the servers performance counters to get an idea of how the app really performs.
Some links to load testing tools are here. Another list is here.
As a side note, I've seen apps start exhibiting strange behavior under a load of only 5 simultaneous users. It really depends on how the site is built.

Resources