A client of mime has an old program running on 4D. I am not familiar with this format, but I have 4 files; a .4DC , .rsr , .4DD and one .4DR file.
I suspect that the data is in the .4DD file. How can I extract the data?
If the 4D application does not have an export function in it then you need to go to the developer to open up the data. Data in 4D applications is accessible only to the application that created the data file. This allows self contained applications to remain proprietary. ODBC connections are great when you have access to the source code, which then lets you separate the data from it's application.
This might not solve your problem, but I hope it explains how the 4D.com product works.
The format of the data is proprietary to 4D and unlike an SQL dump the schema and the data are kept in separate files.
The .4DC contains the compiled code, the gui, and the structure (schema) of the database. The data itself is in the .4DD.
To open the data "back door" so that you can interact with it you need the .4DB which is the uncompiled structure (and code and gui). There is also likely a password required to open the .4DB in designer mode.
4D supports ODBC connections (at least in some versions). If you are lucky that may be enabled and you can access it by running the compiled application and then running your queries against it.
Well I suspect to read a 4D database, you'll need a 4D database client.
I further guess that this is obtainable in the "4D DEVELOPER STANDARD" package, buyable from the maker of 4D. See http://www.4d.com/ .
There might be other (possibly free) solutions, but as long as you don't specify what you want to achieve exactly (just read the data? update it? Modify the database structure? And on what platform?), it is hard to offer useful ideas except for "google that".
Related
I trying to open (using 4d v12) the database with the extension .4dc (in addition there are files with extensions .4dd and .4dr).
The result is an error: You cannot convert compiled database.
Perhaps this is an old version of the database, but I could not find anything that could convert it to a newer version.
My goal is to obtain information from the database. But the problem is that I'm not good at 4d. And I don't know how to open the .4DC as part of an application.
Please help me if you know how to do it.
The .4DC is the compiled structure file. It contains the code of all of your methods and defines the structures (tables, fields) in your database. The .4DD is the actual data file. It contains the values that are stored in the database. The .4DR is the resource file.
You can't edit or convert a .4DC because it is compiled. What you need is the .4DB. It does the same thing as the .4DC (contains methods and db structure), but you can upgrade it and open it interpreted so you can edit the methods and change the database structure.
You can open the .4DC as part of an application, but you won't be able to upgrade it or edit any methods. If you are opening it with the 4D IDE you'll need the same version as created the .4DC in the first place.
You might also try the 4D knowledgebase for more info: http://kb.4d.com or read the documentation: http://doc.4d.com/Home/home.en.html
Good luck!
the .4DC is the application, it's only used to run it. As said it's compile in machine language (0 and 1) so it won't help you out. It's good to use the application, that's it.
the .4DD is the actual database behind the application.
So if you want to access only datas, you should look to this .4DD
There are also ODBC drivers that exists for 4D.
I'm using MySQL.
In my DB there are several tables, containing fields with data, serialized in custom binary format. (Actually, these fields contain lists of fixed-format records, like a "sub-table".)
I need a tool to be able to edit those fields by hand while my own fancy data administration UI is still in development.
I wonder, if there is a DB viewer/editor (like PHPMyAdmin or Sequel Pro or whatever) which I would be able to easily extend to deserialize that extra data?
Note that the [de]serialization library is in plain C and I do not want to spend much time rewriting it in another language. (I would better spend that time on that data administration UI.)
Any clues?
P.S. I need the editor to work on OS X or Ubuntu (Wine is fine) or be web-based.
Sequel Pro is open source, so you can probably get the sources and hack your code in there.
Get it here.
This is a Java app http://www.isqlviewer.com/ . You could load your C library in that using JNI. I've used iSQLviewer a lot with various databases and the download comes with code, but I can't say I've ever looked at the code!
I've been tasked with finding a suitable tool to decompile MDE files. The MDEs were created by staff who have since left (familar story eh?) and we do not have access to the originally MDB files.
The reason we need access to the original code is that the data source is changing (the backend as well as some of the table and queries) and we need a way to update queries. An example of a change, in a SELECT statement where is the WHERE clause looks for zero as a string ("0") rather than an integer.
I'm aware that unless you use the services of people like EverythingAccess.com its unlikely you will ever get the source code back.
My main query is to ask for alternative methods to decompiling code. An example of the kinds of methods I'm thinking about is to spy on the traffic between the app the the ODBC DSN using tcpdump. I might then be able to write code to translate the data source queries between the old and new systems.
Ideally I'd prefer a solution that is application centric rather than one that analyses all network traffic.
I should add one caveat, no doubt most of you are thinking the best solution is to rewrite the code, based on its perceived functionality. This is the option we're not considering (at the moment).
Queries and linked tables can be changed in an MDE.
Alternatively see Converting a Microsoft Access MDE file back into an MDB file. Section 2 for some tips
I see you're already aware of MDE to MDB Conversion Service for Microsoft Access Wayne has stated he will require proof that you own the code.
How to generate DBF files with delphi?
More information:
I need a portable Database to run in a pendrive
I don't know if DBF is the better soluttion.
I like MySql but is hard to find a portable version
I am working with XML at this time but I don't know how to make a Query.
TDBF seems to be one of the most used (and still maintained) packages:
http://tdbf.sourceforge.net/
If you are open to alternative formats, I would strongly recommend you check out Firebird embedded. I'm pretty sure I loaded my database and my application on a flash drive as an experiment about two years ago and it ran fine. I stuck with DBF files for a long time, but once I made the switch, I would never go back. If you want to give this a try, consider using DBExpress and the Interbase driver. Although it's not officially supported, I have not found any incompatibilities. For a visual management tool, get the personal edition of IBExpert.
Not dealt with that in years!
Depending on your version of Delphi and what you want to do, you can either use the BDE or find some specialized components that read/write directly to DBF native file format.
Wow, I'm amazed this url is still valid!
If you want to create a DBF with the BDE API, you can use the techniques here:
http://info.borland.com/devsupport/bde/bdeapiex/dbicreatetable.html
However, depending on the size of the dataset you're going to have, this sounds like a single-user app, which would work just fine with a "MyBase" file -- another name for the files used by TClientDataSet. You can save it either as XML or binary (CDS) format by simply setting the TClientDataSet.FileName property, which will be used to read and write the dataset. You can even create nested datasets with this.
If you want to have the most efficient single user mode, also turn off the ChangeLog on the TClientDataSet.
procedure TFormCDSDataBug.ButtonOpenClick(Sender: TObject);
begin
ClientDataSet1.FileName := ExtractFilePath(Application.ExeName) + 'MyData.cds';
ClientDataSet1.LogChanges := False;
ClientDataSet1.Open;
end;
While I haven't used it, there is a component jdDbf which appears to be recently updated that appears that it will work. Something to be aware of is that the Dbf format has many flavors, however most of the variances appear to be in the index files so if you need to use it with another system you might have to rebuild them.
For a embedded database that works well on a usb drive, I would look at SQLite. There is a Delphi implementation DISQLite3 which has a free and pro version that would work well and comes highly recommended. There are many commercial quality programs currently using it, including the likes of FeedDemon.
Would you recommend working with multiple programmers on an MS Access application?
One of our MS Access application has grown to the point where the number of changes (bug fixes) and new features can no longer be handled by one programmer in the requested time frame.
We are trying to introduce version control using the undocumented SaveAsText and LoadFromText procedures in VBA to make collaboration on this application possible. Unfortunately we have already run into problems loading modified forms and reports back into Access as a checksum is stored in every form text file.
Before putting time into building an import/export application to compile text files into an Access database, we would like to hear your recommendations.
I think you should avoid this path at all cost, and try and persuade management into redevelopment.
It's a bitter pill to swallow, but this is going to need to be redeveloped sooner or later, and you are just saving them time and money.
We were using Microsoft's own version control add-in for MS Access 2000/2002/2003 for about 5 years now, and I can't remember a single serious problem. Usability of this add-in barely deserves a "B", but it must be much, much more convenient than fiddling with any ad-hoc method involving manual or semi-manual exporting/importing of Access forms, modules, etc.
We were using VSS as a version control system all the time. No problems whatsoever. However, if you have some good reasons to avoid VSS, you may have some options:
The version control add-in that we were using does not require VSS. Theoretically it can be used with any version control system that implements Microsoft Source Code Control Interface (MSCCI). For example, when we had to let somebody work on this project remotely, we used SourceOffsite by SourceGear. Access version control add-in worked with this third-party product fairly well (not without some quirks, but well enough). So, if your favorite version control system complies with MSCCI, you could try to use it.
Now that Microsoft has this Team Foundation thingy, apparently there are other options to be used to integrate MS Access with version control. We did not explore this path, though. This article may be a good start for exploring it.
Hope this would be of some help. :-)
P.S. I am not a big fan of MS Access. In fact, I rather hate it as a platform for a user front-end. If I had a choice, I would run away from it yesterday. :-) However, I must admit that existence of this version control add-in is one of the few things that makes maintenance of our old Access+SQLServer project more or less tolerable. :-))
In addition to what I already said here, I should add that the whole system works very well. The comparison process takes less than 30 minutes a week, for a team of 3 programmers. So let's describe it a little bit.
We have basically 2 versions of our Access program:
The "Developer's version", with all the stuff in it.
We each begin to work with an identical version of our developer's edition. As each one modifies or add parts of the code, we have to run some comparison routine on a regular basis. To do so, we have an object-export routine to a common "comparison" folder. An object (module for example) is exported as a text file (saveAsText command, do not work with tables, see infra), it will be compared to the existing equivalent text files in the folder. If files are identical, there is no file exported. If files are different, the new module is exported with the developer's name as an addition to the file name (if modQueries.txt exists, then modQueries_philippe.txt is created...). Of course if there is no equivalent .txt file in the folder, it will be created at first export.
At the end of the period, we would get in our folder the following files
modQueries.txt, being the first "original", last common version of the module
modQueries_Philippe.txt, with Philippe's modifications
modQueries_Denise.txt, with Denise's modifications
As the module was not modified by other developers, their export did not lead to the creation of a specific modQueries_developersName.txt file
If for any reasons Denise exported many times her module, only the last version is in the comparison folder.
We can then compare (with a "text file" comparer) the different versions and create the "updated" version of the module. We have a screen giving us the number of objects in the comparison folder, number of version for each object, and it is even possible to open the file comparer directly from the developer's interface (We use "File Compare Tool" which has a command-line mode and can then be started directly from Access).
The forms compare issue is quite special, as one of our rules is to have no specific code in our forms (please see here for more details). Forms are then only for display, so usually we do not even compare them. We just make sure that each one of them is updated by only one person (which is quite logical).
The table compare issue (we have local tables) can be only made between mdb files. As we export one text file per module, we also export one mdb file per table. We have a small routine allowing us to identify table differences at the structure level or at the record level.
After each comparison procedure, a subroutine will use all the objects available ini the comparison folder and create a whole new clean mdb file from scratch. This is the new developer's version. Every developer can then copy it on his computer and continue his work.
Developer's versions do not have numbers, but contains last client version number.
The client version, with limited stuff, automatically distributed to users
Each developer has the possibility to build a "client" mdb for final users. This mdb is created from scratch, in a way quite similar to our developer's version, but not all objects are exported. Some specific switches are turned off (special keys, access to code, etc). This mdb holds a version number as a property. The version number is used to build the name of the mdb file.
At production time, this mdb file is zipped and placed in a specific "distribution" folder. Each time a user starts the app, it will automatically check this folder to see if a new version is available. If yes, the client mdb file is updated from the distribution folder, and the app is restarted.
This distribution folder is replicated at night time with our overseas agencies. Users abroad will then be able to install the new version on the following day.
Following the direction provided by Yarik we settled on continuing developing in Access using the Access Add-in Source Code Control, the SVN SCC API Plugin by PushOk Software and Subversion. This stack provides us with seamless Access integration, full-backup and restore and an open version control system.
We had to install a hotfix to Access 2003 and make sure the default database file type matched our database file type to make it work.
We will continue to update this answer with our findings.
Have look at this thread:
How do you use version control with Access development?
Sounds like a terribly painful way to do team development. If you have any options for porting to another environment like VS2008 that would be my recommendation.
There is no easy way to work on Access as a team and even version control might be a bit tricky.