Posts made by anthonyh

BOOM. Adding not(OnFirstRecord) to my logic makes it work beautifully.

I THINK I KNOW WHATS HAPPENING!

The first record is getting suppressed because it doesn't have a "previous" record to match to!

So I just need to implement logic to say "if this is record 1 don't do anything".

@DustinB3403 said in Any Crystal Reports Wizards Here?:

So you need to show two records, if the second record matches a particular field in the first record correct?

Why not create a sub-report that will list all records that match anything in the first record?

Because this is already a sub-report.

The desired output is to show the newest record. If the second newest record has the same "name" as the newest record, I need to display both (as this is a flag for the users of said report that they need to fix something in the system).

I've had to reluctantly learn Crystal Reports to develop a multitude of reports for one of our systems that the vendor has refused to develop without a hefty development fee. #JustOneOfManyHats

In any rate, I have a report that pulls the most recent record from a given table. The way I do this is basically I pull all records that match my criteria, sort them in descending order based on their entry date, then put the desired fields in the report header (so only the first record shows). This works beautifully.

However, I've been asked to display the second record in said scenario above if one of the fields matches a field in the first record. Ok, simple enough (or so I thought).

I moved the fields down to the details section and then set a suppression formula as so:

{table.field} <> previous({table.field})

However, it doesn't display the second record. Even if there are only two records and the field's match.

I suspect this is probably due to the order of operations in Crystal Reports. I don't know when it sorts vs when the suppression logic comes into play. I tried adding "whileprintingrecords;" to the suppression logic but it didn't seem to help.

Any ideas?

@Dashrender said in PCI over Ethernet?:

Is your PIAF a VM on your XS platform? is it HA?

It's a VM in our HA pool.

@JaredBusch said in PCI over Ethernet?:

@anthonyh said in PCI over Ethernet?:

@JaredBusch said in PCI over Ethernet?:

@anthonyh First, you need to ignore anyone telling you to switch your PBX. There is nothing wrong with PBX in a Flash. In fact it is a better solution than FreePBX from the point of view that PBX in a Flash uses 100% standard repos. FreePBX uses custom repos.

Functionally they are identical.

On to your problem. Let me ask you this question.

The custom IVR thing uses the PCI card for what exactly? It sounds like they are FXO ports from your description in the first post. because you stated you connected them to an ATA which are typically an FXS device.

Does the software only work via these FXO cards?

They are multi-port FXO cards, yes (I couldn't remember the term!). I do not know exactly how the software interfaces with them. I'm not sure if they are proprietary hardware paired with their software, or if they are off-the-shelf cards that were simply recommended by the software vendor. This system was set up before my time, and has been solid enough that in the 2+ years I've been here I have not even needed to log into the box (though I have logged in so that 1) I knew I could get in if I needed to, and 2) to check it out so I at least kinda-knew what I was working with, lol).

Well even if you get your PCI pass through on XS, you will not have HA because the card is tied to the compute node it is installed in.

I would definitely spend time investigating the software options the vendor has. If there is an option to remove the FXO cards from the picture, you will gain everything you want.

We are going to check with the vendor for sure.

Another thought I had was possible FXO emulation. I wonder if there is a such animal? We could then emulate the FXO interfaces on the server in question and have said emulator simply connect to our PBX via SIP and it all be software and then be nice and portable.

@JaredBusch said in PCI over Ethernet?:

@anthonyh First, you need to ignore anyone telling you to switch your PBX. There is nothing wrong with PBX in a Flash. In fact it is a better solution than FreePBX from the point of view that PBX in a Flash uses 100% standard repos. FreePBX uses custom repos.

Functionally they are identical.

On to your problem. Let me ask you this question.

The custom IVR thing uses the PCI card for what exactly? It sounds like they are FXO ports from your description in the first post. because you stated you connected them to an ATA which are typically an FXS device.

Does the software only work via these FXO cards?

They are multi-port FXO cards, yes (I couldn't remember the term!). I do not know exactly how the software interfaces with them. I'm not sure if they are proprietary hardware paired with their software, or if they are off-the-shelf cards that were simply recommended by the software vendor. This system was set up before my time, and has been solid enough that in the 2+ years I've been here I have not even needed to log into the box (though I have logged in so that 1) I knew I could get in if I needed to, and 2) to check it out so I at least kinda-knew what I was working with, lol).

@scottalanmiller said in PCI over Ethernet?:

Ah check this out... XO was talking about this working but just missing from the XO interface some time ago: https://xen-orchestra.com/forum/topic/25/pci-passthrough-add-ability-to-do-this-from-the-web-interface

Oooh. If this is doable under vanilla XenServer 6.5, then I may be in business. I'm more than comfortable with the CLI. I'll just need to make sure we have a box that has the required hardware features to support it.

@scottalanmiller said in PCI over Ethernet?:

@anthonyh said in PCI over Ethernet?:

@scottalanmiller said in PCI over Ethernet?:

@anthonyh said in PCI over Ethernet?:

@scottalanmiller said in PCI over Ethernet?:

http://wiki.xen.org/wiki/Xen_PCI_Passthrough

Hmm. This looks intimidating (but that has never stopped me). I wonder how well this would translate to the XenServer world though. What would happen when I deploy patches? Hmm. Something to check out though.

DO you need pathces wtih XS 7? I've not looked. It is very current, though.

Holy crap XenServer 7! I feel like I JUST upgraded to 6.5. I'll need to investigate what new features XS 7 brings...

Ha ha. Yeah. This is the "real" update that we have been waiting for post-Citrix era. Lots of the Citrix cruft has been removed and it is dramatically more up to date. NTG Lab has three XS 7 machines slated to come online soon (just waiting on the datacenter to get them ready for us.) I think that you'll want to look there, it very likely will make life a lot easier.

Will do for sure!!!

@Dashrender said in PCI over Ethernet?:

@scottalanmiller said in PCI over Ethernet?:

@anthonyh said in PCI over Ethernet?:

@scottalanmiller said in PCI over Ethernet?:

http://wiki.xen.org/wiki/Xen_PCI_Passthrough

Hmm. This looks intimidating (but that has never stopped me). I wonder how well this would translate to the XenServer world though. What would happen when I deploy patches? Hmm. Something to check out though.

DO you need pathces wtih XS 7? I've not looked. It is very current, though.

I don't think he means today - he means future updates/patches, etc, I'm sure.

Exactly.

@scottalanmiller said in PCI over Ethernet?:

@anthonyh said in PCI over Ethernet?:

@scottalanmiller said in PCI over Ethernet?:

http://wiki.xen.org/wiki/Xen_PCI_Passthrough

Hmm. This looks intimidating (but that has never stopped me). I wonder how well this would translate to the XenServer world though. What would happen when I deploy patches? Hmm. Something to check out though.

DO you need pathces wtih XS 7? I've not looked. It is very current, though.

Holy crap XenServer 7! I feel like I JUST upgraded to 6.5. I'll need to investigate what new features XS 7 brings...

@aaronstuder said in PCI over Ethernet?:

@anthonyh Can you at least get a backup of the physical server?

I can, I just need to figure out a good time to take the box down. Definitely a step 0 in this project for sure.

@scottalanmiller said in PCI over Ethernet?:

What about the PCI passthrough for Xen? Did that look promising?

Is it an advertised feature from Citrix? I will admit I didn't re-google to see if this feature was newly "blessed" by Citrix. However, when I went through the 6.5 upgrade a while back there was no mention of it as far as I know. I know you can do GPU passhtrough, but not sure about PCI passthrough out of the box. I should re-research. The link you provided is a good start though.

@aaronstuder said in PCI over Ethernet?:

Let's start with the basic's:

What OS is that last physical server on?

This server is running Server 2008 R2 I believe.

@Dashrender said in PCI over Ethernet?:

@anthonyh said in PCI over Ethernet?:

Ok, this thread is derailing fast....

So how much did you pay for the old hardware solution and who built it?

Do they have a solution that works directly with today's PBX IVRs?

Good question. This system was implemented before my time. No clue what it cost. Definitely going to query the vendor if it's looking like my only option.

@Dashrender said in PCI over Ethernet?:

Who wrote the IVR interface? Do they offer other non PCI options in light of PBX IVR solutions these days?

20 years ago, Nuance sold hardware solution IVR cards, today they sell IVR software that does the same thing and ditches the hardware requirement.

Of course management says - hey why do I have to spend money replacing something that works perfectly well - so good luck with that.

On my list is to query the vendor to see if they have a VoIP based solution. The system isn't as old as you may think. It's victim to the niche market which usually aren't up to snuff when it comes to modern technologies (hence the analog voice cards to ATA MacGuyvering :D).

I suspect if they have a solution it'll be expensive, but if it's our only option I'll push for it.

@scottalanmiller said in PCI over Ethernet?:

http://wiki.xen.org/wiki/Xen_PCI_Passthrough

Hmm. This looks intimidating (but that has never stopped me). I wonder how well this would translate to the XenServer world though. What would happen when I deploy patches? Hmm. Something to check out though.

@Dashrender said in PCI over Ethernet?:

hate to suggest it - why not do VMWare for that one box? You could use the free version, and if you have a client based Backup solution you can do backups.

I thought about this. It's an option. Not ideal, but definitely on the list.

I think some of you are stuck on "IVR" and thinking "Oh just make your phone system do that." It's more complicated than that and I will explain:

The system I am talking about is an IVR interface for our Jury Management System (I work for a court). It interfaces with said JMS system and allows Jurors to check when they need to report for jury duty and submit any responses requested based on the Juror Summons they received in the mail. They key in their badge number, their last name, and then based on their jury duty history are then presented with various options (check whether or not they need to report for jury duty, request an excuse from jury service if they are eligible for exclusion based on their jury duty history, update their juror information, respond to supplemental juror questions if there are any, etc.).

Hopefully this makes it a little clearer. If it was a simple IVR tree I would have already re-crated it in our PBX.

I'm also going to append this to the OP.

@scottalanmiller said in PCI over Ethernet?:

@anthonyh said in PCI over Ethernet?:

Why change something that we have aboslutely no issues with? It wouldn't save us any money....

Doesn't it? Are the physical IVRs going to be free forever and carry zero risk? If not, it seems like it does save money, at least eventually. It also protects you from something you don't have protection from today AND solves the problem that you are trying to solve here, right?

Give me a minute to type up a post. I'll explain what this IVR system is and it should make sense after that.