I have a group of files that have extensions of .dat & .idx. They seem to be named in pairs. These files were under a folder named deeds.dbs. How do I access this data? Sorry for the general question, but I know nothing about Informix at all.
Yes; the names you give (directory 'deeds.dbs' and contents in pairs of files, xyz.dat and xyz.idx) are very characteristic of Informix SE. The database would be called 'deeds'. You can find the manuals for SE at the IBM web site.
There was an earlier - much earlier, as in last updated in 1986 - product called Informix 3.30 (with no qualified name like Informix SE or Informix OnLine). Informix would have used a file 'deeds.dbd' to contain the database dictionary for the 'deeds' database (hence the suffix) and would have used the C-ISAM files (such as file.dat, file.idx) in the same directory (usually) as the '.dbd' file.
Related
I have a graph working fully with the plugin locally in neo4j desktop. I've replicated everything from this graph in my grapheneDB instance. I can't use the gds procedures as I get the error:
gds.proc... is unavailable because it is sandboxed and has dependencies outside of the sandbox. Sandboxing is controlled by the dbms.security.procedures.unrestricted setting. Only unrestrict procedures you can trust with access to database internals.
I know to fix this I need to add these two lines to the config/properties file:
dbms.security.procedures.unrestricted=apoc.*,gds.*
dbms.security.procedures.whitelist=apoc.*,gds.*
I just dont know how to do that on grapheneDB, I've read all the docs I can find.
I've tried adding the gds plugin by adding the jar file as just a stored procedure and then also as a server extension with a zip file containing both the jar file and the two config lines mention above in a neo4j-server.properties file.
When added as a server extension I can tell neo4j hasnt found the gds plugin at all. Am I just missing a location in the properties file? Or am I missing something obvious in the stored procedure upload method?
Using the dev free tier graphenedb, Neo4j Community Edition 3.5.17 and graph data science 1.1.1
Thanks
After a couple of weeks back and forth with graphene support, the config changes have been made. They will be adding support for the GDS plugin as part of their base image soon, but until then you may still need to request that they patch your db for you and add it as a stored procedure.
i got a customer who wants to migrate from an old Fujitsu COBOL based system to our system, said that, he wants his old data to be kept in the new system, like products,manufacters, etc.I dont have the COBOL source file, i have: .DAT files, .RDD files and .FDD files.
Apparently the .DAT files are in the INDEXED organization, a sample file output bellow:
FDD output:http://textuploader.com/kxdv
RDD output:http://textuploader.com/kxdw
I can't simple read the .DAT file in notepad, i've tried the SiberDataViewer but unsuccesfull, also it gets paid to export the data.
If there's a way, can i write a program to export all these files to csv,dbf,postgres format? If you are still reading, thank you.
I do not know Fujitsu COBOL but as I see it there are a few ways you might be able to get at the data:
0) Have your customer (or someone with a compatible Fujitsu COBOL compiler) write a COBOL program to read the INDEXED file and output a SEQUENTIAL file.
1) Find a Fujitsu COBOL utility to do the same.
2) Find a product that can read the INDEXED file and export it into something you can use. I'm thinking of products like Cyberquery or Crystal Reports, etc. Or, after I saw that the FDD/RDD files were produced by Siber Systems, a quick search helped me find their "Cobol DataViewer" product; use that to output it to a "more common and usable format" ;-)
I could convert it using the Siber DataViewer, but, its full version is paid.
I have a friend who has a management application, and he would like to import some of his data in Excel.
The thing is I have no idea about how to read this type of files,
In his application directory he has a folder named app.dbs. Inside there are *.idx and *.dat files.
What would be the easiest way to read this files? Maybe ODBC connector, or installing some version of Informix DB??
That sounds like C-ISAM files, or an Informix-SE (Standard Engine) install. You most certainly can't read them directly. Googling Informix C-ISAM files ODBC generates plenty of results. Also this page explains the relationship between the two.
I've never used SE, but assuming its installation is reasonably similar to its big brother Informix Dynamic Server (and I believe it is), have a look on your friend's computer for an 'Informix' directory. You may find an %INFORMIXDIR% environment variable to point you in the right direction. Within that, look for an executable in its subdirectory bin called dbaccess.exe. Run that from a DOS prompt and you should hopefully get an SQL interpreter that allows you to read and extract the data.
If you have no luck finding such a directory, then it's more than likely the "management application" is writing C-ISAM directly, and you'll need an ODBC driver for C-ISAM, as you surmised.
The name app.dbs containing the .dat and .idx files is an almost sure indication that you have an Informix SE (Standard Engine) database (someone might have faked it, but it is pretty improbable).
Given that you may be able to use an Informix ODBC driver and SE itself to access the database, or you may be able to use an ISAM-based ODBC driver to access the database. It depends in part on whether this is a one-time migration or an ongoing access while the application continues to work on the database.
Assuming all of this is installed on Windows, you should indeed find a %INFORMIXDIR% directory, which will have a dbaccess.exe in the bin sub-directory, and an sqlexec.exe either in the bin directory or in the lib directory (it would be in $INFORMIXDIR/lib on Unix; I'm not sure about Windows). These should be able to access the database. If you find sqlexec but not dbaccess, then you've got a seriously old version (more than 20 years old, but I know of other people still using such archaic versions). You should be able to identify the version by running dbaccess -V or sqlexec -V. If it is 7.25, it is reasonably recent (that's been current for a decade or more); if it is older than that, it is verging on the archaic.
Suppose I have three separate applications called MyPasswordManager, MyToolManager and MyMovieManager. Each of these applications uses a Firebird Embedded database.
If a customer buys all three of my aplications and installs them on his/her computer. And my customer has all three applications running at the same time, what happens?
Will the Firebird dll's have conflicts? What do you do in this situation?
If you put the Firebird dll's in the application folder (where the .exe is) there won't be a problem since this is the first place where your application will look for them.
You have to make sure that the applications each install to their own folder, if you want to use different versions of the dll's.
Cape, you really ought to read the "readme_embedded.txt" file in the doc directory - it has all the answers youre looking for. Some relevant quotes (for the FB 2.5 version):
2.2. Database access
The database file can be accessed by multiple client
programs. The database consistency in this case is
guaranteed internally (by the shared lock table).
2.4. Compatibility
You may run any number of applications with the embedded
server without any conflicts. Having IB/FB server running
is not a problem either.
have you tested it in your dev machine? I think just putting the apps and the dlls in different folders each one could work. Maybe renaming the dlls with different names can work too
How source code is stored in SQL server for TFS2010.Is it possible to see it by digging the Database?
Versions of checked-in files are indeed stored in the database, which is basically just a simple blob store that contains a mix of the entire version controlled files as well as "deltas" between them.
That is to say that the server will occasionally store the differences between two versions of the files using a binary delta algorithm. For example, for a file $/Project/File.txt, version 1 may be stored intact but version 2 may be stored as the delta from version 1. When a client requests version 2 of $/Project/File.txt, the file may be reassembled from deltas before delivery.
The database is intended to be treated as an opaque data store and is generally not supported. In order to interact with your version control programmatically, it is intended that you would use the very rich APIs that are available for communicating with Team Foundation Server, either from .NET
or from Java.