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.
Related
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".
I asked a question here a while back and using the answers, made some head way in figuring out how my DOS based legacy software works.
My problem: The software uses Btrieve to read/store data in .dbk files. I know this because the DDF files reference these dbk files. I found a number of ways to open btrieve data but only if they are stored in .btr files.
Anyone has any hints? I've spent considerable amount of time digging through resources but to no avail. All I need right now is to see the data stored in the dbk files in a readable format.
If your DDFs reference .DBK files, you should, using a version of Btrieve / Pervasive that supports it, be able to use ODBC to read the data.
Create the ODBC DSN pointing to your DDFs and Data Files.
Once created, use your favorite export tool to export the data to your favorite format.
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.
I've recently been given a MS Access .mdb database file and asked to make it usable in a Linux system. What I'm looking for is a way to convert the Access database to an open-source database such as MySQL or PostGres.
I don't have MS Office, and it's a one-time project for a volunteer organization so I don't want to spend money if it's avoidable. I'm running Vista x64, and have a Linux virtualbox, so something usable in either one will be good.
Forunately you don't need MS Access to get data out of an Access database. While there are tools like MDBTools that will read .mdb files on Linux, I've found them to be unstable for larger, more complicated databases. The best way is to use ADO or ODBC on Windows to export the data from the .mdb database into a format you can import somewhere else (like csv).
I've had good luck using DBI with Ruby, or using ADO in a Ruby script.
Following links may be useful for you.
MySQL:
access migrate
read.php?65,27115,27115
PostgreSQL:
Microsoft Access to PostgreSQL Conversion
Converting from other Databases to PostgreSQL
I used the MySQL Migration Toolkit and it worked very well for tables, even creating a reusable script. It is free and simple to use.
This toolkit is now EOL and the MySQL Workbench 5.2 replaces it.
Unfortunately, it falls over with "A problem caused the program to stop working correctly" when I try it with MS Access on my system. At the last step, of course. (Jan 16 2013)
Either MySQL or Postgres will work fine as a replacement data store for your access data. If your Access database contains Forms or Reports there really isn't a direct replacement in Open Source, and you'll either need to retain the Access front end and access the data using ODBC drivers, or code a new series of Forms or Reports in PHP or your favorite web scripting language.
I had the same problem now, and found this freeware to be exactly what I needed: http://www.bullzip.com/products/a2m/info.php
It extracted everything from the MDB file generated an SQL file I imported directly into my MySQL server.
There are two parts to the process
1) convert from Access database to scripts, there are some good options although you may need Access and potentially Sql Server too, to do this
2) Pick your target database - MySql would seem like a good fit, run it up on Linux or Windows and run the ddl and data in from the scripts.
Not sure how you can do this without Access though, do you have any idea what the schema looks like? If you do run into probs I could help out with step 1, but I don't have a Linux install at the moment.
i beg to differ: there is no need to use external tools or costly middleware. the simplest, cleanest, cheapest, fastest, safest (did i say BEST?) solution is using ODBC and integrating fully.