I'm trying to connect to a database supplied by a vendor. I have read-only access.
Every tool I use (SQLWorkbench, DBeaver, etc...) refuses to connect using the jconn4 drivers with an error message along the lines of:
Metadata accessor information was not found on this database. Please install the required tables as mentioned in the jConnect documentation.
Normally the fix is easy. Run:
ALTER DATABASE Upgrade JCONNECT ON
Unfortunately in this instance, I only have read-only access and the vendor refuses to turn it on. Apparently with good reason. I took a snapshot of the Windows server, then did a few tricks in the background to get access to the database with read/write privileges and ran the command. Then I restarted the database server. Every client that uses the database started crashing and throwing bizarre errors. I rolled back to the backup and called the vendor and played dumb. They immediately knew the issue and said "somehow someone turned on metadata accessor tables--good thing you had a backup" and that was the end of it.
Is it possible to access the database without turning on those tables? Are they specifically related to using jconn4 for connecting? Is there another way to connect? (I don't pretend to understand anything about the jconn4 library or Sybase--I rabidly dislike both things). Ideally I would love to be able to browse tables and key relationships with a GUI, but I'd settle for just being able to execute SQL commands and get results while testing.
Related
It has been requested of me to dump an entire database hosted on MS SQL Server 2005 with multiple tables for a third party to then import/use.
My first thought was to find something like mysqld_dump that would give them import commands, which lead me to the "generate scripts" with schema and data, which should work.
one concern with this option is data that has primary/foreign key requirements, does the script it creates keep this in mind, should it be no problem? I am doing a test import now to attempt to verify this; thought I would mention it.
It was suggested for quicker resolution to just dismount the database and give them the MDF file. I am not sure I like this idea, as I am not so familiar with everything that gets stored in this file. Is it a security risk to our server at all? is there references stored in this file that specifically relate to our server that may allow for damages?
My main concern is security here, as long as they get the data everyone will be happy.
Any advise or even better alternatives that i have not thought of would be greatly appreciated.
Thanks
Why don't you just backup and restore the database to a server that the 3rd party has access to, or deploy it on a server for them and restrict their access and only give them ability to run scripts and other basic permissions?
As I've posted on this thread I need keep synchronized an SQL Server (not only SQL Server, if you recommend another server which do the same thing) and VFP DBF tables to use on the systems of the company.
As #alex-k said, Linked Server doesn't support INSERT, UPDATE nor DELETE but I need the CRUD statements to the systems work. I've already tried the suggestion of #alex-k but returns error.
As a lot of things in computation has more than one way, what do you recommend to my situation?
Thanks.
I've actually just installed SQL2008R2 on an old machine. Successfully created a linked server and tried the update direct from within SQL. Ran into your same error that it won't work. So, I looked around too and found something on "tek-Tips" forum that descdribed opening a rowset to apply an update via this link
When trying that, I got a follow-up error listed below.
SQL Server blocked access to STATEMENT 'OpenRowset/OpenDatasource' of component 'Ad Hoc Distributed Queries' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Ad Hoc Distributed Queries' by using sp_configure. For more information about enabling 'Ad Hoc Distributed Queries', see "Surface Area Configuration" in SQL Server Books Online.
Since I don't want to open up features regarding security, even on a machine just for sample purposes, you might be more open to enabling/disabling this feature and trying the suggestion from tek-tips...
Good luck otherwise.
Today DBF files are not widely supported. As far as I know Microsoft Access still supports dBASE DBF files which should be compatible with VFP DBFs.
You can build some kind of gateway in MS Access responsible for synchronizing VFP and SQL Servers databases.
I have not used them since their pre-apollo days (uit sed to be called successware or SDE), but this company might have something that will help. The problem you are going to encounter with other solutions that can read-write the dbfs is that they might not be able to keep the index files up to date (cdx, ndx, etc). If they don't have a driver that helps, you might have to resort to creating an extended stored procedure to natively call their interface. Hopefully you won't have to resort to that.
-don
Have you considered building a small Visual FoxPro application to do this. Visual FoxPro can read and write to both SQL Server and DBFs. We have done this numerous times. The key is to understand what records have changed, and using surrogate primary keys on both sets of data.
Rick
My customer is a dental practice that has bought a piece of practice management software. This software was installed on their local server, including a patient database, a schedule and all manner of medical records. Now they want me to write some utilities for them that aren't provided with their package, and for this I need the ability to query this database.
I tried calling tech support of the software manufacturers (Patterson/EagleSoft), and it's difficult finding anyone who understands the technology enough to answer my questions. As far as I can tell, there's no API for their software, and understandably they're reluctant to tell me how to query the DB directly, programmatically. They do have an interactive query window, but obviously that's no good for writing automated queries. All that they would let on is that somewhere there's a SQL Server DB, but the ODBC drivers to connect to it are SQL Anywhere drivers (huh?).
So I searched around on the server and couldn't find any database files. Then I discovered that the installation creates some kind of proprietary virtual machine, which is only visible to the EagleSoft software. But while they've been very good at insulating their DB in layers of obfuscation, they have left open an ODBC driver, which is indeed an SQL Anywhere connection.
Now after that fascinating and lengthy preamble, here is my question: What queries can I run over this ODBC connection to interrogate the DB as to its structure? If it's a SQL Server DB underneath I could use the sysobjects table, but I don't fully grasp how you can use a SQL Anywhere ODBC connection to connect to a MSSQL DB. And If they were misinforming me and it really is a SQL Anywhere DB underneath, what are the queries to run to get at the DB structure?
And if there's anyone else out there who's ever succeeded in actually querying EagleSoft (or any similar proprietary package) - please tell me how you did it!
Turns out the simplest way to do it was to write a little app using OdbcDbConnection, and connect using the DSN installed with the software. It took one probing 'select * from sysobjects' to reveal that it is, indeed a MS-SQL database underneath all that, and I'm good to go from there!
I'd use a tool like squirel which is great at browsing any database to check if anyone was successful with "SQL Anywhere" this google result:
http://blog.gmane.org/gmane.comp.db.squirrel-sql.users/month=20091001
Shows that others have managed to get squirrel to do this. It's quite easy to use... assuming of course you manage to get the connection working!
A few tools that might help are SQLWorkbench and Django. I use SQLWorkbench to copy the data from the production system into a Postgres database so I can hack on it without damaging the production environment. Then I use Django's inspectdb to generate models of the database environment. From there it's easy to create 'views' into the database and templates to display exactly what I want.
UPDATE: As of Eaglesoft 19, it looks like Patterson has password protected the database and they have gone out of their way to prevent users from getting at the data without paying them for access.
UPDATE: Like I mentioned before, Eaglesoft 19 has a locked-down version of the database. For read-only access you can call Patterson and ask them for the password to the "Database Admin" section of their "Technical Reference" tool that is installed on your server. Once you are in there, there's an option to set a read-only password for access to the database. The username is 'dba' and whatever password you set. Some times it takes a bit of back-and-forth with them to give you access, but my solution was to say "We've been putting patient data into Eaglesoft for over a decade and we've always had access to the database. Now you're restricting it and telling us we have to pay for access. It sounds like you are trying to extort money by holding our data hostage. I should probably run this by our legal team."
EDIT: Nov 18 2022: You can still easily get read-only access to an Eaglesoft database in 21.20.08 (the latest version) by calling Patterson and getting the "day password" for Technical Reference. From there you can enable a read-only user. Based on some of the changes Patterson is making to their application architecture and the database, I suspect they will stop using direct connections to the database in the next year or two. When they make that change, you will only be able to access the database through their API Server. After playing "phone tag" with one of their salesbros for several weeks and doing some light social engineering, I managed to get their price list for going through the API server. It's atrocious. Most offices pay ~$500/mo to Patterson for free tech support and free upgrades. They want developers to pay nearly as much per office for access to the API. They've realized they can lock practices out of their own data and monetize it. We are working with a company that is actively developing a replacement for Eaglesoft to get away from this horrible vendor lock-in.
I have written my own PHP driven website to access and manipulate data in my eaglesoft database. You simply create odbc connection to local DNS entry and done. To see database structure you can use the technical reference included in eaglesoft or advanced query tool.
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.
In the place I work, very often it happens that a developer and QA session goes like this:
(This is in reference to SQL Server 2005)
QA: I get Invalid object name 'customers'
DEV: huh? can u send me the exact SQL statement you used?
QA: select * from customers
DEV: hmm. (after some thinks) Are you sure you're using CUSTDB?
QA: yes
DEV: (after figuring out that QA was using CUSTDB_PRODUCTION) Please add "USE CUSTDB" and then tell me what you get with that SQL.
QA: Oh, sorry, I was using wrong DB.
The tab-text for the SQL window shows the information of which database the query is running on, but how do you ensure that QA follows this?
I will admit that I have made this mistake of using the wrong DB many times. I don't tend to read the text in the tab.
What are your experiences with this type of scenario? Have you found a way to help mitigate such a problem?
if your QA is using SSMS for testing you should try the window coloring options in SSMS Tools Pack free add-in for SSMS. this way you could immediately differentiate between servers.
if that's not an option don't allow QA to access production server at all. they shouldn't be able to anyway.
I think you need to formalise how QA will report an error.
You need to specify a set of information that they'll supply with every error report, including:
what they were doing (exactly)
their configuration (including the database!)
time/date (so you can match stuff in logs)
how to repeat it (if repeatable)
etc. You can act on that immediately, or log it in an incident tracking system and come back to it later (in which case the above is invaluable, otherwise it's all lost).
The above can be as simple as an email draft/template. But you need to be rigorous about this, otherwise (as you've discovered) you're going to go round in circles, perhaps without all the salient information you require.
If QA are allowed access to both live and dev databases, using SSMS, then there must be some level of accepted responsibility on their part and/or some level of training of them on your part.
They have been given a tool that allows them to ask questions of the data, but are asking the wrong questions, then complaining to you - if I was the DBA, I'd simply remove their access until they could demonstrate they knew what they where doing! I sympathise that that might not go down to well, but at least threatening to do it might make them think a little for themselves.
Think of this question as 'someone is doing something wrong'
There are 2 simple answers:
remove their ability to 'do something wrong'
train them to do it right
On the same note as Mladen Prajdic, you can colour code query windows in SQL2008 SSMS too.
Personally I use the fully qualified name in all queries (server.datatabase.owner.table - well I only use server if I'm deliberately using a linked server) because I move from database to database so much. If you specify the database in the queries to be run, they still work if connected to a differnt database on the same server or if you have a linked server. Have your QA adopt doing this as their standard if they are writing their own queries; if you are writing the test queries then you should be specifying the database name in the query not through a use statment.