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.
Related
I realize how vague this question is going to be, unfortunately I'm at the end of my rope in trying to solve the issue.
My company has a .net 2.0 app we wrote. It uses Microsoft SQL Server for it's database. We have been deploying it with no issue for a long while. Our most recent deployment had the Database installed on MSQL Server 2014, it was originally created on 2005. After the installation of the database, and the installation of the client application, the program runs great for about 4 days. After those 4 days, it takes about a minute to log in (Using ASPNET) After log in some of the data pulls do not work. For example the main screen gathers a set of records based on the user who has logged in, this list won't populate. However if you open the screen for assigning the user to those records, the records and the user assignment populates with no issue. Of course with the weird data problems, the app is running incredibly slow. This also has never occurred. The installation in question is on Windows 7 and 10, both OS's we have installed to before with out incident.
Any thought on a possible direction for troubleshooting this would be appreciated, I have hit it from several angles with no luck.
Thanks again.
So the answer to this problem was to turn on ANSI nulls in all of my stored procedures. Due to how vague my question is I'm not posting this as an answer. However the issue is resolved and I'm adding this comment for the sake of completeness.
I'm having trouble figuring out databases in VB.NET. (VS 2008)
What control(s) do I need to use and how do I use them? I am ,looking for tutorials and sample code too.
I'm working on a trivia game where the admin can remove and add questions to a database.
EDIT:
The program must be able to do all of the DB interactions itself through code.
Regarding DB portability...
I do not intend to install it on many machines, so portability is not a major issue, but I's rather not be bound to Access or SQL Server. (Is that possible? - A portable database file?)
A bit more complaining...
I really need help with connection strings and the whole DB gamut in VB. I've done DBs in PHP so I'm not completely ignorant. It's the VB side of things that's confusing.
Thanks.
Have you considered SQLite DB? It's a very small DB and is used my many vendors. I have not used SQLite personally, but I do know that Firefox uses it and so does iPhone (from what i've read).
SQLite does not require you to install anything (as per the post below). It's a nice alternative to Access or carrying around SQL Server Express.
If you do decide to use SQL Server Express, you will be required to install the run-time, from here for each machine it's used on.
Below are some links which may help you get started
Google for SQLite DB
ADO.NET 2.0 Provider for SQLite
And finally, here's a blog post outlining how to get it done, and quickly.
Cheers!
I would suggest Microsoft's Enterprise Library - The hands on labs available make it a breeze to setup access to a database, and can make it as simple as a config change to point to a new/different DB.
Also, check out http://connectionstrings.com/ for related info.
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.
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.
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.