I know cleaning cache will work because tables are cached. But a certain line in my script causing problems here is the content. Please help me understand the line highlighted in bold.
// create table
CREATE CACHED TABLE JMS_MESSAGES(MESSAGEID INTEGER NOT NULL,DESTINATION VARCHAR(255) NOT NULL,TXID INTEGER,TXOP CHAR(1),MESSAGEBLOB OBJECT,PRIMARY KEY(MESSAGEID,DESTINATION))
// create indexes
CREATE INDEX JMS_MESSAGES_TXOP_TXID ON JMS_MESSAGES(TXOP,TXID)
CREATE INDEX JMS_MESSAGES_DESTINATION ON JMS_MESSAGES(DESTINATION)
// what is it doing? because this line makes it hang
SET TABLE JMS_MESSAGES INDEX'3883576 3883576 3883576 0'
Please let me know what this line does so I can debug this script. On production we are using Jboss 4.0.4 and don't often clear tmp/work often and reboot system every Sunday.
Simply delete the line reported in bold and save the .script file with no other change.
The purpose of the line is to link to the data in the .data file. As this is a message cache that is no longer valid, there should be no data there.
Related
our test server was hacked and they installed a ransomware (Cry36) for which there is no solution to date. We also didn't keep any snapshots up to date (lesion learned).
Since it's only a test server, i am not too worried. But we had stored in our Firebird DB (v2.5) a bunch of work which i would like to save.
Looking at the database in a hex editor, i can see that the data is encrypted up until offset 00006430.
Looking at the structure of the firebird database it says that all the headers are encrypted (Header page, PIP,..., Data page).
All the data is still there.
I've tryed with gfix and even copying the headers from an older version of the db. But while it does fix the db, the headers are wrong and most of the new pages are removed.
Does anyone have any idea how to restore the database or extract the tables?
Regards
I have used this method restoring ransomware files encrypted on hard drives from any ransomware by renaming the file in question back to its original filename and extension. You may be able to apply the same method to revert the data or database back to the pre-encrypted version of the file/s or data/bases.
From my testing:
the ransomed file = is compressed and or simply renamed, the encryption is either not applied actually but only implied or the containing file or renamed file is encrypted but the original file is never touched. Simply rename back to original and you can access the file as you could be for the attack. Example:
This is the Ransomed file:
Adobe Acrobat XI Pro 11.0.20.zip.id[42AF04FF-2275].[supportcrypt2019#cock.li].Adame
This is the Ransomed file, renamed and fixed:
Adobe Acrobat XI Pro 11.0.20.zip
The removed portion of the FileName is:
.id[42AF04FF-2275].[supportcrypt2019#cock.li].Adame
Upon renaming the file, you will be prompted for approval to change the application type/ file type for which the file will be opened (Back to its original state), and what application will open it (its original designation as determined by the FileType preset after the FileName. The reason the file doesn't work when ransomed is the final file extension renaming scheme, whereas in this case .ADAME is not a real file type, but made up, and no program will or can open it. Thus, the file can not be opened as named.
You would need to do this for each file individually, could you post more information on the database file and encryption information as this should work for you as well. The Ransom Methodology should be the same. I can not identify the naming scheme used on your system without more information pertaining to unusual or new/unidentified portions of code injected throughout your instance.
For Renaming multiple files you could try an application such as "Advanced Renamer" for bulk processing.
We have several processes which generate temporary references in the form
"TMPxxxx" where x is a digit. These appear to be used for session
temporary file names, and for keys in the usrw_wkfl table. I¹m not sure if
these are generated by QAD (MFG/Pro), or Progress, or just by the individual
programs.
A colleague has suggested they come from Progress/Openedge, but I can't find
anything in the documentation, or any references on the web either for QAD
or Progress, hence this question.
If there is a standard process within Progress/Openedge or QAD for this could
somebody point me in the right direction please?
Thanks!
TMPxxxx session id is created by QAD(MFG/PRO) an ERP application.
There is an Security control menu item (mostly menu number: 36.3.24) in MFG/PRO (QAD) and field that name is "Session ID Prefix".
It's used for temporary system-generated work file (creation when login, deletion when logout). Exp: qad_wkfl, sr_wkfl and some file creation in temp directory.
You can monitor users who get TMP id for which session.
for each mon_mstr no-lock:
display
mon_userid column-label "Mfg/Pro User ID"
mon_program column-label "Mfg/Pro Program Name"
mon_sid column-label "Mfg/Pro Temp Session Id"
mon__qadi01 column-label "Progress Session Id".
end.
Maybe too late but I hope this will help you
OpenEdge creates various temporary files while the session is active. Each file has a 3-character prefix followed by a random number. The different prefixes are:
dbi: Stores temporary tables
lbi: Local before-image file (subtransaction undo)
ped: Edit buffer contents
rcd: Cache of r-code being run in a session
srt: Temporary sort space; session compile storage
trp: Stores Data Dictionary changes until they are saved
Sometimes the random number is the process ID of the Progress session, but not always. The location of these files can be controlled with the -T startup parameter.
Here is a Progress knowledge base article about the temp files:
http://knowledgebase.progress.com/articles/Article/P111424
Here is the Progress online documentation:
https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dpabl/temporary-file-i-2fo.html
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
When I go to check something into MorphX VCS right now, I get the following message:
Cannot create a record in SysVersionControlMorphXRevisionTable (SysVersionControlMorphXRevisionTable).
The record already exists.
With things that have already been checked out once, I've been able to resolve this with a get latest and then a new checkout/check in. However, when it comes to doing an Add, I'm completely stuck. Is there a resolution to this or have we completely borked our VCS?
Note: this error is only given when we try to check in from a development project. Checking in directly on the AOT does not give this issue.
Just look at the table SysVersionControlMorphXRevisionTable (in SQL if you can't access) and see what the duplicate record could be. The unique index is ItemPath and Version. I doubt you'll see anything here though.
It's most likely an issue with the call in this method \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\latestVersionNumber where it's trying to get the current highest revision and is being called by \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\create.
Put a breakpoint in the create method line #48 and see what revision.Version is, and before the insert, check in SQL if the ItemPath/Version already exists in SQL.
I'd guess it's probably a server/client-caching issue. To resolve, refresh all of your client caches under Tools>Caches. If this doesn't resolve, and it's a good idea to do anyway, copy these menu items:
\Menu Items\Action\SysFlushAOD
\Menu Items\Action\SysFlushData
\Menu Items\Action\SysFlushDictionary
\Menu Items\Action\SysFlushReportServer
To a new menu item and change the property RunOn = Server. Then run these and it'll flush your server caches. If this still doesn't work, try restarting the AOS.
If this doesn't work, your users application user cache files might be corrupt. Close your client and delete the *.auc and *.kti files in %LocalAppData% folder (Typically C:\Users\[user]\AppData\Local) and reopen your client.
In the environment you are using, have you restored a copy of another database somewhat recently?
Edit: Now knowing that you did a DB restore, there is a good chance your GLOBALGUID was reused and/or is causing caching issues. See here for more info about how/why this happens.
You should probably stop your AOS and run these SQL commands:
UPDATE SYSSQMSETTINGS SET GLOBALGUID = '00000000-0000-0000-0000-000000000000'
DELETE FROM SYSCLIENTSESSIONS
DELETE FROM SYSSERVERSESSIONS
Are/were you also having issues with batches running? (Somewhat related, but I'm mainly just curious on this question)
While using tAccessInput component in my job, it showing error like,
It may not be a database that your application recognizes, or the file may be corrupt.
But, it all the connections and database/table names are valid in my job.
What can be the problem. and how can i resolve it.
Metioning the exact DBVersion is more important for tAccessInput/tAccessOutput.
Like Access 2003/Access 2007 and associated database file name.