sundance-communications.com/forum Forums TDM Business Telephone Systems Samsung Telephones & Systems Latest Dataview Problems

I just learned today that the most recent release of Dataview is reflecting innacurate data and this release was suppose to "Fix" this. Our most recent issue is that Dataview is displaying more agents (20) logged out of the Group than actual number of Agent in the group (16). How the heL* can that be? Samsung explained that on the previous version, there were no problems at all. They state they tested and use internally and all is fine.

ANYONE ELSE HAVE INNACURATE DATAVIEW ISSUES?

I'm getting tired of hearing that no one else is reporting these problems just to hear weeks later their is a new release to fix the problems.

This is Dataview folks. Reporting. Don't release until tested Samsung!

Mine works fine on current software.

They probably did test it, and they probably have it working just fine. I would find out every piece of what they are using. What operating system the software is running on and what version of OS, what phone system is it connected to and what version is the phone system on. There must be something different about your installation that is cuasing this. Have you tried tech support to go over your dataview installation? Have you taken the online dataview test and are you certified on the product?

DefaulRebuild_again,

We are having issues as well. I think what most people over look is how can the data be verified. What appeared to be initially functioning properly is actually not when drilled down. For Example, I feel most users simply look at the data in Dataview and "Trust" that it's correct. We have a customer that was using an earlier version of Dataview and it was working fine. But, when something else went squirly on their system, Samsung suggested that moving them into 2.69 would fix the issues. When upgrading, the 2.69 Software busted the Dataview. The customer then had to upgrade to the latest Dataview which was really screwed up. Remember the 10 seat limit? Well after 5 months, Samsung fixed the 10 seat issue but somehow busted something else. The reports are all off, even today. The reports are showing over a 4 hour hold queue timer when it has been verified that no caller is in queue! We also are getting the same type of report that shows more agents logged out than are in the entire system! Of course we are the only ones with this problem...

So you are not the only one with this problem. As late as yesterday, We understand that Samsung knows of the "Innacurate" report and is attempting to fix it (Heard this before). It was working fine until Samsung broke it. I also spoke to a good dealer friend of mine in the NorthEast. He says about a year ago he was told by Samsung that Dataview was flawless. He installed in a very well know name call center and the reports were displaying inacurate number back then. The customer kicked him and his sytem out. Apparently Samsung flew up to the account and couldn't fix it (Initials DC). My question is why is this still being sold when there are known problems? Makes you wonder doesn't it?

Bring back the 400!

Sam Sung

What system and current software version are you using? How have you verified all is fine? What testing have you done?

2.69L 500 dual cabinet. 2.2.0.5 Link and ive been running the newest version of dataview on the gsbn for some time now. I saw the 10 seat version before, and is fixed with current release. I have not had any issues with too many agents. I run daily UCD reports per agent along with constant logging of SMDR. I can agree that i have seen discrepancies, but never more than 1 call at most in a days period, but no data network is perfect. The call stuck in queue when no call is there is the one that Samsung is working on. I think Shawn has seen it too.

You certainly could be onto something, bestboards, but do you have any data to back it up? Do you have any scenarios that you know fail? I will certainly try them on my customer's dataview application.

Instead of bashing Samsung and wishing for hardware that will never return, let's reproduce something with proper troubleshooting. I have never had much of a problem reporting an issue when i have data to back it up. I talk to Tech Suppt all the time.

Sam Sung,

If you've been running the GSBN for some time now, you're not using the current version. It has just recently been released. 1.5.1.2 is most current version.

Latest as of today, the Duration Column reports are way off. Reports reflect 44:32.13 hours for callers in queue, Ringing for 22:17:10 hours, Logged out for 39:53.21 hours.... We confirmed that this is innacurate and basically near improbable.

Since this is in Samsung's back yard (Dallas Area), they have been invited to review this site to pull reports, view debug or trace files (Oh sorry, they don't have these...) in order to fix these problems.

Apparently Samsung is aware of these problems according to Distribution, but will not specify what the problems are. Go figure. I just want the sh*) fixed!

Good luck, i give up on your cause, you are way too negative. And i have been running 1.5.1.2 for over 7 weeks now. Good luck my friend.

OK, let's roll back the aggression a tad.

If you have a problem come to me or tech support and ask for help. If you yell at me I will do exactly what you would do if I were yelling at you: I will disregard everything you say.

When 2.48 was being developed the switch engineer saw some CTI link events he thought were useless so he removed them. As a result we got the issue where only infor for the first 10 agents was sent.

2.69 did correct that in that he added those events back in. There's no side effect to that. It didn't break anything else or add anything else.

Regardless of what you may think I did, do, and will continue to test DataView every single day. I have 4 sites running in huose in addition to 8 systems in the lab running various switch loads, DataView versions, and operating systems.

I test every single screen, monitor every single number, and verify it all against both switch UCD reports and SMDR reports. I don't release a version of software until I am confident it has no problems.

That said, obviously there's no such thing as a trouble-free software release because no matter how good your test plan or lab systems there is *always* something you don't see or can't test for.

We *do* have debug and trace files, the issue is that to date 90% of the calls that get to tech support or get escalated to me are either user error or site problems, so don't warrant looking through debug or trace data. To date every report of numbers not being accurate has been proven incorrect.

There is currently 1, count them, *1* glaring issue with DataView. Stuck calls. Stuck calls are what cause you to see 22 hour hold times or 12 hour ring times. They will cause numbers to be wrong, but not through miscalculation it's through a few big numbers.

If you're getting stuck calls I don't need to visit your site or look at your logs. I *know* what the problem is already. But this isn't a process I can snap my fingers to solve.

I am trying to fix it the best way I can given what I have to work with, but let me go through the problem with you.

A call hits the switch. The MCP generates an event and sends it to Link, who translates it to a TAPI event and sends it out. DataView, who is listening for those events, picks it up and logs it. The web interface sees the change when the screen refreshes and updates the screen if necessary (in this case it would update any trunk monitor to show that trunk is now ringing).

When the call gets to an agent another event is generated and goes through the process to now show that agent is ringing.

When the call is answer, held, transferred, disconnected, or undergoes ANY status change, an event is generated.

If you're following along there's 4 points of failure here:
The packet between the MCP and Link can get lost.
The Link PC processor can be under heavy load or any kind of major system slowdown causing the event to be overlooked.
The packet between Link and DataView can get dropped (it's an IP packet even if they reside on the same machine).
The DataView PC processor can be under a heavy load or something causing the event to be overlooked.

In any of these 4 cases you end up with a "stuck" call. The answer event gets missed so you get an agent ringing forever, you miss a disconnect so there's a call that's huge.

You can clear stuck calls as you see them through the Collector (right click the system icon in the upper left, go to About, click Reset, enter the trunk or agent port number and click Reset), but admittedly that isn't a good option. It's at best a bandaid to prevent reports from being skewed, and it's not really an end user process.

I'm not going to sit here and tell you tht "hey, I can't help you because it's a network or PC problem." Instead I have been trying to find away to prevent dropped packets from being an issue within the guidelines of the current CTI architecture.

If you're me, how do you solve this problem? Have the switch send status updates of every port every tenth of a second? I cna do that if I decide crashing the MCP from the load is OK.

Have DataView ping the switch for status updates every second? OK, if we want to triple the system requirements AND risk crashing the MCP.

It's not an easy thing to overcome. But it isn't as if I have given up. I work on it a little every day. There's a team of coders in Korea trying my ideas and testing every day. We're making headway, but it's not a total solution.

The last thing i am willing to do is release somethign to you guys that "helps a little." If it's not a fix, I won't send it.

The standard answer that tech support is supposed to be giving is basically what I have said above: that stuck calls can occur due to network OR processor lag.

I know you all think it's a canned BS answer, and that YOUR customer's network is absolutely infallible and their PC is the next best thing to quantum computing, but we all know that isn't the case.

I have 3 of 4 internal sites who have never seen this problem in over 2 years of running DataView, on 500s, 7100s, and 7400s. I also have one internal site that gets it quite frequently, because their MCP is about 10 miles from their server (they're in a different building and their server is here).

The simple fact is that factors out of my control cause the problem. I am tasked with finding a way to compensate for something I can't control. It's not a simple task, it takes time.

If you want to have a peaceful dialogue about it, send me a message and I can help you.