Micros SIM Error

[GAMicrosUser]

Hi Micros Experts,

I have a location that is giving an odd error message when executing a SIM interface.

The message reads:
ISL Error on Line 90:5
Duplicate Variable Def(DLL Handle)

I have installed this same SIM interface in over 100 of our locations with no issues like this.

To troubleshoot the issue, I stripped the functionality out of the SIM so all that it is setup to do now is pop up a message box that says "Hello". It still returns the same error message. The stripped down SIM only has a couple of lines, not 90 as referenced in the error message.

The I have tested on multiple workstations in this location and get the same error on each workstation.

Everything has been rebooted multiple times.

The licensing looks fine.

We have sent down an EM resynchronization packet to the store with no luck either.

Anyone have any experience with this type of error that is noted above? Any asistance would be greatly appreciated.

 

[DrZogg]

Read line 90 of the SIM for the answer. It is telling you there is a variable named there that has been declared earlier and is still there.

 

[GAMicrosUser]

I have removed all of the content of the SIM to where it now only produces a message box saying "Test". It is a 3 line SIM. There is no longer 90+ lines in it. Yet it still gives the error message about line 90.

I also forgot to mention there are other SIMs running at this location. It just seems that any new SIM I try gives the error message.

 

[pmegan]

It sounds like that error is coming from one of the other SIM's they have running. Double check the interface your touchscreen button is linked to. I've made that mistake once or twice and wasted a lot of time chasing an error in my script that didn't exist. Also, if you remove your SIM altogether what happens? Do you still get that error when you send and/or close the check?

 

[GAMicrosUser]

Hey pmegan,

I only get this error when I setup a new SIM interface. It does not matter what the contents of the script is. Very simple or complex code, it returns an error about line 90. There are not 90 lines in any of the simple scripts I am testing with.

The error goes away as soon as I delete the new interface in POS Config.

If I add it back the error returns so I am pretty sure it is related to any new SIM.

It seems like the original SIM is stuck in memory or something.

 

[pmegan]

Does this happen on the server as well, or just on the workstations?
Also, are the stores currently using this SIM running the same interfaces as the one that's giving you grief? It might be helpful if another store has the same setup.

I'd try putting the .isl and supporting .dll files from that system on a test server and see if you get the same error. If you do, remove the .isl files one at a time until the problem stops. DLL_Handle is a pretty popular variable name when using external libraries, so maybe there's a conflict in one of the other scripts.

 

[GAMicrosUser]

This is an odd one. I have the same script running in over 100 locations all on imaged machines. The error occurs when I run it on the back office pc as well as counter workstations.

I am baffled. If I run just a simple script that pops up a message box to say "Hello" it throws the line 90 error. No .dll's are being called and there are definately not 90 lines in the script.

Scratching my head for a couple of weeks on this one.

 

[pmegan]

Try moving the other .isl files in the server's etc folder into a temp folder when the store is closed and then try your script on the server. Something is conflicting, and it doesn't seem to be in your script.

 

[DrZogg]

Is it the same ISL # in interfaces the sane as the name of the pms.isl? Is it calling another script at all?

Paste the 3 lines up here to assist. If you are running RES 4.5 onwards, you must reload the database after changing interface details in Configurator. (Startup hangs also if there are incomplete SIM settings).

What Enhanced Interface version are you running also? I have all the versions if you need one. Is the SIM present on the local \etc as well as on the server?

Send us also details of the interface setup in configurator (SIM, port 5009, 127.0.0.1, turn on logging.

Also, open the log viewer and observe what RES is logging about the error

 

[GAMicrosUser]

pmegan, DrZogg - Thanks for your assistance. You have both given me some good things to look into.

I like the idea of removing the other scripts running on the machine and isolating the issue a bit more.

We are running Res 4.3 in our environment.

I have run the script on the back office pc as well as the workstations and it behaves the same on all machines. It has been in the \etc folders on all machines as well.

The crazy thing is it doesnt give any useful info in the log either, just the same ISL Error on Line 90:5 Duplicate Variable Def(DLL Handle) message. No other details.

I will be out of town next week but as soon as I get back in the office on 6/20 I will post some additional details after I try the suggestions that have been presented.

This community of experts is very helpful and appreciated.

 

[GAMicrosUser]

I finally got back in the office this morning to do some more testing on this issue.

I must say this commuinity of experts is fantastic.

I tried the suggestion of eliminating the other SIMs and the very first one I disbaled turned out to be the culprit.

After correcting the bad SIM, I am now able to run my new on with no issue at all.

Thanks again to all that offered assistance.

 

[michelle305]

While attempting to preview a report from the Autosequence module using RES 3700 4.7 I receive error "519, no print window found". (or close to the error) I know this is dependent on the report you are trying to run. I found a solution that says to edit the Store Procedures comments (?). How is this accomplished and how do you know which stored procedures to edit??

I know I am missing some info, but any help would be appreciated.
thank you

 

[GAMicrosUser]

Is the report a custom report?

I ask because I have come across the no print window error several times when running one of our custom reports.

To resolve the issue, I delete the stored procedure associated with the report and reinstall the report.

Not sure if it applies in your environment but works everytime for me.