I am invoking the service ‘wm.tn.doc.xml:routeXml’ from one of my flow services. I am passing content and contentType fields as input. But I am getting following error:
com.wm.app.b2b.server.ServiceException: Couldnt insert new document
(0) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-01401: inserted value too large for column
(1) java.sql.SQLException: [wm-cjdbc33-0009][Oracle JDBC Driver][Oracle]ORA-01401: inserted value too large for column
at wm.tn.doc.persist(doc.java:789)
…
…
…
…
I am not sure why this error occurs ? I was succeeded previously with the same content.
I tried the same input passing to the wm.tn:receive service, but it also throws the same error.
We are also facing the same issue on our Prod TN since 2:00 pm today.Assumed to be DB error. Seems like we have some greater issue.
Please keep posted if any updates.
Have you tried recycling the IS/TN or reloading the TN related packages?
Also try to use small size xml document or create a new dummy document in TN and then push it to TN using ISAdminConsole/WmTNWeb document submission,if this works then try using routeXML service by just providing node as input.
We just got off the phone with Tech Support. It’s a Global issue with TN creating a 25-byte Bizdoc Document ID and trying to insert it into a 24-byte field on the database. They’re working on a fix and will publish it as soon as they can.
Can everyone with this issue post your database and wM server versions? Maybe we can find a common thread. We’re on webMethods 6.1 and Oracle 9.2.0.3. We’re seeing the issue on both HP/UX and Windows 2000 servers.
RMG - we’ve tried all different types of documents and server restarts, nothing has worked yet.
Wow! We just started seeing that today as well in Dev/Test. I’m going to try not logging content in the Doctype settings until I can figure out what’s going on. But how weird that everyone’s seeing this at the same time. Do we have an embedded virus of some sort here?
Dave - thanks for posting that. I figured it was something like that from the errors, but couldn’t find any data to support the theory. Any idea how they discovered exactly where the problem was?
Michael - I doubt we’re talking about a virus. More likely webMethod simply used the date somehow in their algorithm for generating the bizdoc ID, and at a certain time that algorithm generated a larger number than they expected.
Hello,
we are seeing the same problem. We are on WM601 on a sun 5.8 with oracle 8.17. Our sever has been working fine for month at a time, why all of a sudden today we would the same issue?
Regards,
Hello,
we are seeing the same problem. We are on WM601 on a sun 5.8 with oracle 8.17. Our sever has been working fine for month at a time, why all of a sudden today we would the same issue?
Regards,
Yes I see, thanks. Jonathan, as Skip suggested, there’s undoubtedly some date/time-based component in the internal DocumentID that caused this string to just today become larger than the 24 bytes allocated to it in the Bizdoc table. Let’s keep an eye out for a Fix from support.