[Anthony Thompson]

Rob, I see two issues.

First and importantly, you said you imported all the historical data but it doesn’t look like FILES that were attached to the old forum posts are available. That’s a real shame because sometimes people posted very useful files.

For example, in this thread (https://usspvlclovertch2.infor.com/forums/topic/921-db_vista-user-id-check-failed-adt_serviceclient/) Terry Kellum seems to say he posted a Quick Guide file with his post. However there’s no such file in the new forum.

I’m sure there are the standard responses about files being out of date, etc. But in many cases I’d much rather look at an old file, even with caveats, than no file at all – which is just frustrating in its omission.

Second, why is there no way to reply to old threads?

Many times things that were posted years ago are still relevant. In the same example I posted above, even though it was posted in 2015 the error still occurs today, and I’d like to contribute to the main thread so that someone else who has the issue can see my response.

Unfortunately, there doesn’t seem to be a way to reply to that thread. At the bottom of the page all it says is “The forum ‘Cloverleaf’ is closed to new topics and replies”, which again is disappointing.

While I understand that the old forums were deprecated and finally nixed by the security team, they were better in at least two ways: They kept old files posted by users, and you could reply to a thread even years later (which I frequently saw happen, by the way).

[Anthony Thompson]

(I know this is a rather late reply to this thread, but in case anyone in the future has a similar question.)

I had a similar desire for new development, automated testing of tcl scripts/procs. I ended up mocking the Cloverleaf environment with a library and then using the built-in tcltest package to run the test.

However like creating any comprehensive unit test for code, it’s time consuming. I use it for new development but only go back and add unit tests to old code if I have to rework it substantially.

Depending on how many tcl procs you have, it would be pretty time consuming to go back and add such tests for all the tcl procs in a code base. But it is a great way to document requirements during new development and then have something to run when change requests come in down the road.

[Anthony Thompson]

To help future people who find this thread by searching, if the -c flag to hcidbdump for showing context still doesn’t give you enough info, you can use something like

Code:

hcidbdump -e -m 1213239 /path/to/some/tempfile

to save the message which caused the error to /path/to/some/tempfile, then use the Testing Tool -> TPS to test the Tcl code with that HL7 message as the input.

[Author]

Replies