Write Error code 12345

josh

HI, our OI is not working atm. We can read,but can't write. The write error code is 12345. Does anyone know what 12345 means?

josh

Never mind, I found post on the rev forums about this error code.

But apparently the team has already tried what was advised in the post, and still doesn't work. So it's something else.

-----------------------------------------------------------------------------------------------------------------------------------------------------

https://www.revelation.com/revweb/oecgi4p.php/O4W_RUN_FORM?INQID=WORKS_READ&SUMMARY=1&KEY=16593.48044*214872A8C243AEFEFEC88E4D1#/section/breadcrumb/UPDATETABLE/Display

josh

Seems to be working now...scary. OI is one big mystery. Where can you get resources explaining how OI works?

DonBakke

Any technology is a mystery to a great deal of people. I don't think OI is unique in this area. What kind of resources are you thinking of? Using a technology you are more familiar with, what have you come across that explains how that technology works?

josh

Ok, to give a basic example. Let's say I wanted to debug our website. Since I understand JavaScript and I understand HTTP, I am in a very good position to debug any issue that happens with our website. Also, I can easily see what is going on using the developer tools of the browser.

Now with OI, I have no idea where to even begin looking when something with the UDH stops working, because I fundamentally don't know what UDH is, what it does, why there are so many different kinds of UDHs (UDH, UD NULL, UD DRIVER, UD HEAVY -- what do all of these word mean, which one are we using???)

I wish there were a resource that explained what happens when I execute a WRITE or READ statement in OI -- from my client to it being sent to the UDH, to what the UDH does with it , to the UDH returning the result to the client.

DonBakke

Thank you for the analogy. I believe it reinforces my point. I feel just as lost when I try to work with a full web stack. I'm much more comfortable with HTTP than I used to be because of all the research I did to build a RESTful framework for OI...but JavaScript, HTML, DOM, etc., is still a mystery to me.

The advantage that other technologies have is that they are more widely used and therefore have many more places you can go to search for answers. Having said that, I've observed many JS developers get stumped and answers have been scarce.

There are ways to monitor the internal operations of OpenInsight. I've documented these in a couple of blog articles and others (like Sprezzatura) have documented this in their S/ENL newsletters. Even the Revelation site has a few Knowlegebase articles on this topic.

I still contend that all technologies require proper training (or equivalent experience) in order to know how to ask the right questions, where to ask them, and how to interpret the answers.

Based on prior conversations with you, my understanding is that you got thrust into managing an OI application with minimal (or no) training. If that is true, then I highly recommend you request this.

josh

Thankfully there are other people here, and it's not just me, but no one is very familiar with the linear hash/ud program. I will look through the knowledge base. We have sent an email to revelation, so hopefully they can help us.

JaredBratu

I've only ever seen the FS12345 error with the UDH (Universal Driver Heavy) and since you've gotten it resolved I won't speculate above what was previously mentioned in the post:

This will occur when the client attempts to write to a table managed by the UDH if the UDH was restarted while in an inconsistent state, for example a server crash or a hard shutdown and one of the journal files wasn't properly closed. To prevent the system from getting into an inconsistent state all writes are disabled until the journal files are cleared and the system is re-copied to the backup server.

If you are using the UDH it might be worth looking into using VM real-time replication and the UD 5 (Universal Driver 5). The UDH does a good job at replication LinearHash database tables but it's a little brittle when dealing with non-LinearHash database changes which are often also important to an application's proper functioning.

Here is a short summary of what the acronyms UDH, UD NULL, UD DRIVER, and UD HEAVY refer to. They all refer to the server-side database service that provides multi-user access to the LK/OV files (LinearHash Database files for OpenInsight). The UD (Universal Driver) technically has two parts:

1) The server-side LinearHash service in the Windows Services list and it's corresponding management program on the server.
2) The client-side database driver for OpenInsight which is accessible by running netdrv.exe in the root OpenInsight directory.

So generally when people talk about the UD on the server it's the LinearHash or UD Manager and on the client it's what was selected in netdrv.exe

Here are the two primary differences between each:

• UDH (Universal Driver Heavy) - A LinearHash database service designed for real-time replication of LK/OV files to a secondary server for applications with high-availability requirements.
  
• UD (Universal Driver) - The normal and most widely used LinearHash database service.
  
• UD NUL (Universal Driver Network User License) - A special version of the UD which is locked to a particular version of OpenInsight. It's a version that is bundled with OpenInsight and limited to working with the version it was bundled with.
  

Hopes this helps...

josh

Thanks,

Yes that does help.

How come I can't see a process for netdrv.exe in task manager? I am running OI right now on my computer. Is this because it's a library, even though the file extension is .exe?

DonBakke

Netdrv.exe is only ran when someone wants to change the client driver. It isn't used by OI when it is launched.

josh

Oh, i thought it contained the code that communicated a read/write/lock from the client to the lh server. I must have misunderstood.

josh

We have now figured out that the IT Department had done pen testing on the computer running the UDH at exactly the time the UDH crashed. They are claiming however that their pen testing, which apparently tries to connect to every single port on the computer and send rubbish data to it , couldn't have caused the UDH to crash.

I believe that the UDH is listening on TCP ports 777 and 999. What effect on the UDH would sending rubbish data on those ports have?

DonBakke

Actually, we have seen this very thing happen with other sites. Jared has worked closely with these sites and with Revelation so I'll defer to his recollection on these situations and how Revelation responded. As I recall, however, there wasn't much they could do for our clients.

josh

They have now admitted that what they did caused the issue. So mystery solved.