I am developing Delphi 7 application, which is operating with Access Database (MDB format). It works fine on my PC, and some other PCs as well. But on some machines application gives error when trying to access database sometimes, saying something like "Unkown database format (mdb)". Additionally I noticed one thing: When you open that database in Ms Access using Office, it is opened in "read-only" mode for some reason. Can anybody help? What could be the reason for the problem?
It's been a long time since I have programed in Delphi, but I remember I had issues with different versions of MDAC installed. Compare the versions between the pc's that work and those that don't.
I think your most likely problem is to do with MDAC, use the registry to check what version is on each machine and see if there is a differnce between the ones that work and the ones that dont.
I used to get that error message if the database file (the mdb file) was actually set to read-only (for example, if it had been copied off a CD). Check the file properties in Windows Explorer and ensure the file isn't read-only.
Also, have you tried doing a Compact & Repair within Access, as Access databases regularly corrupt and this option can often help cause all manner of problems.
What version of Access is the MDB formatted for? Are you using DAO or ADO to access the databases. Is the MDB in 2003 or 2007? I suspect it's in A2007 format and the machines you are having troubles with have A2003 installed or no version of Access at all. Whereas the machines that work do have A2007 installed on them. But that's just a guess.
You also need to track down the read only problem too.
You say: "It works fine on my PC, and some other PCs as well."
Then it sounds like there might not be anything wrong with your program. What it could be is that the PCs it won't work on all the time do not have Microsoft Office or at least Microsoft Access installed. They need to have Access installed for ADO to work.
A "sometimes" problem on a machine is difficult to diagnose without further clues.
I'm afraid I don't know what the "Read-only" problem might be.
Related
I installed Access Database Engine in order to open a database using RStudio and everything is fine. However when I installed the package, Microsoft Access can't start which means that if I try opening any Access file or creating any new one, it won't open.
Therefore, there is incompatibility issue between Access file and Access Database Engine, since I tried this process on two different platforms and got the same problem. Therefore, I appreciate any ideas or solutions regarding fixing the issue using registry or other suggestions.
As Andre altready mentioned - there is a misunderstanding on your side. Access runtime can ONLY open existing databases for data entry, nothing else. No alteration of forms, no new reports, and especially no new table or database. For stuff like this you need the whole access application, which is part of office and far from free.
We have an application that makes use of OLEDB and the Jet engine Microsoft.Jet.OLEDB.4.0. We are converting our application to also run in 64-bit mode. However, the database engine is no longer a standard part of 64-bit Windows. But Office 2010 64-bit does install a 64-bit access database engine (See http://www.microsoft.com/downloads/en/details.aspx?familyid=C06B8369-60DD-4B64-A44B-84B371EDE16D&displaylang=en) so you can use Microsoft.ACE.OLEDB.12.0.
So I am working on fixing issues so that our application runs in 64-bit mode as well. But the OLEDB code complains about the database engine not being registered. So I try to install the redistributable 64-bit engine on the above link. But it tells me I need to uninstall 32-bit Office 2007 first. No way am I going to do that, because I am sure some settings etc. will be lost.
So my questions are:
How is that the 32-bit database access components do not work in 64-bit mode, but you cant install the 64-bit one if the 32-bit is installed already? Does that make any sense to anyone at all?!
I realize Microsoft wants people to switch to SQL server Express, except it is too invasive, does install reliably even on clean new Windows 7 computers, and it is not simple to copy or move the data around between different machines. Is there a suitable alternative to Jet then? Something that is simple but works on 32 and 64 bit and ideally has OLEDB and ODBC support? SQLite looks promising maybe?
Just did a quick search and there doesn't seem to be alot of alternatives to Access without going to SQL server. I found This, http://www.vistadb.net/, which sounds cool but the developers license is pretty expensive.
As an alternative, you can still use Access without installing the 64 bit driver. This happened to me, had to read from Access but could not convert the app to 32 bit. My answer was to write a separate 'proxy' executable that would run in 32 bit. I'd start the app using the System.Diagnostics.Process object and communicate with it through redirected standard input and output, passing the connection string as a command line parameter. The DataTable class has built in ReadXML and WriteXML functions which makes passing the data like this easy.
I have an old compiled Access Application mde file. This application has linked tables to network shared folder. I tried to upgrade main database using upsizing wizard on main database and everything went well. Then when the application starts it gives error message that
Microsoft jet database engine cannot find the input table or query table
I have checked the shared mdb file it has exact table names and everything.
Then I called the guy who developed this application. He said I have to rewrite the application to not use Jet engine...
What does Jet Engine has to do with linking tables? Do I really have to rewrite the whole application to use ADO?
Many questions:
do you have the source MDB file? I can't recall if creating an MDE fails if the linked tables are not correctly connected. In any event, should you end up needing to alter the app, you're going to need the source MDB file.
the error message you report should give the name of the missing table.
do you know when the error is being reported? There could be any number of places where simply replacing tables linked to a Jet MDB back end with ODBC links to a server will not fix things. For instance, should there be any saved queries or SQL in code that bypasses linked tables and uses a direct connection string, that could produce an error like you see.
in regard to the developer's response that "I have to rewrite the application to not use Jet engine..." either you misunderstood what he said, or your developer is completely incompetent. Or both, I guess. Jet works very well with ODBC linked tables and if you're using an MDB front end, it is impossible to completely eliminate Jet, as the MDB is a Jet data file. The desire to eliminate Jet mostly comes from people who can't be bothered to learn how to use it properly.
It sounds to me as though you're getting an unhandled errror but insufficient information on what's producing it. You need the actual MDB to troubleshoot it, as the code isn't there to display in the MDE so there's no way to figure out what the actual source of the problem is. If your developer won't give you the MDB, then you need to check the contract under which the app was developed -- if you agreed to letting him control the source code, you're basically at his mercy and should fire whoever signed off on that. For what it's worth, when I deliver an MDE to a client, they also get the full MDB. They generally don't do anything with it, but should I no longer be available to do further development work, they've got the source code that they can give to whomever they want.
Last of all, I think it's very unlikely that even if you get your app working, a mere upsizing is going to offer much in terms of performance or stability. It is true that very often, 90% or more of an upsized app will work without alteration, but the other 10% can be very problematic. Often you need to move certain operations server-side to get the efficiency a server back end offers. This means your front end app needs to be re-architected to work better with your upsized back end. The degree to which this is true will differ from app to app, but it's very seldom that absolutely everything works without revision.
You did change Access database version?
It is possible that your mdb was linked with old version of Jet drivers and these drivers cannot connect to newer mdb version.
we have just experienced a weird error on our applications connecting to a clustered Sql Server 2000: both our .NET applications (ADO.NET) and C++ (ADO) application get an error which we cannot explain.
All the applications can connect to the database, can read data from it but cannot write data on it, receiving a "Generic network error" (I've translated from the Italian message). After several trials, we tried to switch the services from one node to the other, and this seems to have solved the problem.
Still no one is able to figure out what happened and why; is there anybody who is able to explain to me?
Thanks in advance
Marco
EDIT:
Just in case it happens to someone else: we found out that the computer didn't have the last version of MDAC (2.8 SP1). It's very likely that the customer reinstalled the computer and didn't update Windows: when we ran Windows Update, the problem magically (from the customer point of view...) was fixed.
We don't know exactly which version of MDAC was installed, but could have been 2.6 or less, since I know our applications have problems with older versions of MDAC.
Applied any updates recently?
I have seen something similar on later versions of SQLServer so I would have a look at the security access to the server etc as I don't think they all replicate from system to system.
Is it possible to use e.g. SQLite with PowerBuilder? I need an embedded open source database (no additional costs).
Like Bernard said, you'll need an ODBC driver, so as long as you're willing to go third party (if I understand the SQLite situation correctly), that should be no problem.
That said, if you have PowerBuilder, you have license to distribute the single-user SQL Anywhere run time engine. If no-cost is your only criteria, and you're only connecting locally, SQL Anywhere may be an option to evaluate. Not only is it an incredibly solid database, but there's a much larger base of documentation and experience connecting PowerBuilder to SQL Anywhere, so if you run into problems, you're more likely to get some help.
Good luck.
I don't believe that PowerBuilder contains a driver for native support to SQLite. But it definitely has a driver for ODBC, so that is always an option even if it isn't the most efficient one.
I used to use SQL Anywhere, but eventually ditched it for the reasons Joe Landau gave - can't change the schema using the distributable runtime engine.
I switched to Firebird, which has an embedded version, and that seems solid. The only issue is that the ODBC driver I'm using (Gemini), which seems to be the best one available, seems to have gone out of business. (I just checked - it seems to be available on other sites.) And you have to add the following to your PBODB*.INI file:
[Firebird]
PBSyntax='Firebird_SYNTAX'
PBNoCatalog='YES'
[Firebird_SYNTAX]
CreateTable='CREATE TABLE &TableName (::ColumnElement[::ColumnElement]...)'
ColumnElement='&ColumnName &DataType'
DropTable='DROP TABLE &TableName'
GetIdentity='Select gen_id(GEN_&TableName,0) from RDB$DATABASE'
I've been very happy with it. Using it for almost 2 years, with over 1,000 users, and no problems whatsoever. You can also easily switch to the Firebird server version if some users need that.
As noted, SQL Anywhere is available and solid. But it has a disadvantage--you can't change the schema using the run time engine. This makes it hard to, say, add a column to a db that you have distributed.
++ to the comments by DC on Firebird. One of the best free databases out there. I have used it for years for a PB application I sell to Law Firms.
Although I use the server version even if the target is a single workstation. Simplifies the deployment and the issue of adding workstations later if desired.
I use the standard Firebird ODBC driver at http://www.firebirdsql.org/index.php?op=files&id=odbc
There are two good GUI front database management tools that I hve used - IBOConsole and Flamerobin.