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
Related
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.
My question is this: Are there alternatives to ODBC that would allow us to connect our SQL Server to MS Access?
Here's the situation: My company works with a proprietary, SQL database (ProVenue) that up and decided to "no longer support ODBC" to MS Access, our front-end tool, without telling us.
We are currently migrating away from ProVenue, but in the meantime , we're stuck with a vendor, which "no longer supports" our ODBC connection(s). The vendor also has no incentive to help since we're leaving in several months.
I've devised a workaround where I manually export the ProVenue tables (ASCII), proof (yes, the export utiliy pulls unreliably), convert and upload on a daily basis into Access. That said, it is unreasonably time consuming given the number of tables. This work-around could be a full-time job.
Do you know of any alternatives?
Do NOT consider using ADP. It has been dropped from Access 2013 and hence is a technology with no future.
From what you're saying, you don't "own" your own MSSQL database - you're simply connecting to an instance that the provider manages, correct? I would guess that they've disabled ODBC connections to MSSQL because they don't like the load placed on their servers and/or that they've decided they want to change some underlying structures and don't want to have to cope with anybody whining about those changes.
That said, do they allow direct MSSQL connections? Via SQL Management Studio, for example? If so, you should be able to define an export & import process which is less buggy than theirs, and simply re-point your Access database to the local copy of data. True, this would still require some (possibly automated) import process, so you'd be out of synch with the server, but it'd give you the solution.
You might try connecting an .adp file to the server, to see if they'll still let you access things in that manner. That would possibly require significant modifications to your Access solution, but would also be a bit easier on their servers than linked tables via ODBC.
You could have a look at Access Data Projects (ADP) which are tied directly to one SQL Server database. I don't think they use ODBC at all, but they have their own limitations, and of course, aren't available in older Access versions.
Is there seriously no way of using a shared access non-server driven database file format without having to use an SQL Server? The Entity Framework is great, and it's not until I've completely finished designing my database model, getting SQL Server Compact Edition 4.0 to work with Visual Studio that I find out that it basically cannot be run off a network drive and be used by multiple users. I appreciate I should have done some research!
The only other way as far as I can tell is to have to set up an SQL server, something which I doubt I would be able to do. I'm searching for possible ways to use it with Access databases (which can be shared on a network drive) but this seems either difficult or impossible.
Would I have to go back to typed DataSets or even manually coding the SQL code?
Another alternative is to try using SQL
Install SQL Server express. Access is not supported by EF at all and my experience with file based databases (Access, SQL Server CE) is mostly:
If you need some very small mostly readonly data to persist in database you can use them (good for code tables but in the same time such data can be simply stored in XML).
If you expect some concurrent traffic and often writing into DB + larger data sets their performance and usability drops quickly. They are mostly useful for local storage for single user.
I'm not sure how this relates for example to SQLite. To generate database from model for SQLite you need special T4 template (using correct SQL syntax).
Have you tried SQLite? It has a SQL provider, and as far as I know EF supports any provider. Since it's file-based, that might be a plausible solution. It's also free.
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.
Looks like the TSQLConnection only connects to existing databases, and I could not find another component that allows me to send commands to the database server.
I'm using Delphi 2009 with Firebird and MSSQL.
One idea that came was to connect to a system database (master or tempdb in MSSQL for example) and then send create commands to the server. This could be an option for MSSQL, but I'm not sure for Firebird.
I'm also aware of the new DBX metadata in Delphi 2009, but I couldn't find a way to create databases using it. All examples I've found is to modify existing databases.
Yes, you can. dbExpress now includes a powerful set of meta-data classes for doing just that.
Steve Shaughnessy gives a good introduction here.
Erick if you use Devart drivers you can connect without the databasename parameter and send the t-sql create database command.
dbExpress included in Delphi uses a "least common denominator" strategy. Information like query statistics which is available through native drivers is invisible with dbExpress. (Maybe I should ask a question like "Which feature in alternative dbExpress implementations made you switch?")
You can execute "CREATE DATABASE ..." on both databases with standard TSQLQuery.
Note that syntax differes between these two. Since dbx is lightweight lib, this SQL and DB specific action probbably will never be fully supported. It leaves you with SQL.
With Delphi 2007/2009 comes DBX4. You may use the low level structures there to create database programmatically. Look in dbxcommons.pas
You can send a "CREATE DATABASE" script through any connection (ADO, OLEDB, ODBC, etc) opened on any server (or even ms-access files) as long as it follows the specific server DDL syntax.