I have to read two .dbf files that came from a VFP server in SQL and manipulate them. They are sitting in a folder on the server. First, I have installed the VFPOLEDB driver, the ODBC driver, and its update. I have successfully created a linked server to the free tables, and tested it in SQL and it says the connection is fine and there's stuff there. I still can't seem to even look at the files. Anyone see anything wrong with my code? Or any tips? Sample code of known working code? I have found a lot of examples online, but when I apply with the many hours I put into modifying them, they still don't work.
Here is my code:
Select * From OPENQUERY(LINKEDSVR, 'Select * from employee.dbf')
LINKEDSVR parameter info:
Provider: Microsoft OLE DB Provider for ODBC Drivers
Product Name: Microsoft Visual FoxPro Driver
Data source: linkedfoxpro
ODBC linkedfoxpro config:
Datasource name: linkedfoxpro
databasetype: Free Table Directory
Path: c:\somefolder
Driver: Microsoft FoxPro VFP Drver (*.dbf)
Thanks!
Those CDX files are not generated by SQL - that's the index file created/used by VFP. They are very prone to corruption so it is likely that the CDX was already corrupted when you got it or in transit.
By deleting the CDX file, you have removed all indexes from the table and also the source of the error.
Related
I am a beginner in Microsoft Access and one of my friend gave me a copy of his SQL Server file and something with .BAK extension which I believe is the database as it is almost 300MB.
When I try to run the SQL Server file I get cannot connect to backend database error. Searching on the internet I found that I can prevent this by holding shift while opening the database.
Even though this does open the Access file, where I can see all the table,queries, forms, reports and macros icons and names. I cannot open any of them. When I press on one of the table names for example I get
Connection Failed SQL server does not exist or access denied' error.
How do I view the tables?
Your MS Access file is linked to a SQL Server. You basically need to
Install SQL Server Express (it's free)
https://www.microsoft.com/en-au/sql-server/sql-server-editions-express
Restore the .BAK file into SQL Server Express How to import a bak file into SQL Server Express
Relink all of the MS Access linked tables to your installed SQL Server
How does one change the connection string of linked tables in MS Access
This may seem complicated but it is a great opportunity to learn about databases.
Seems your friend is not very helpful.
I need to create a procedure to upload data from an MS Excel spreadsheet to SQL server on command. My background is in Access VBA I am attempting to use either of the below Distributed Query methods as described on the Microsoft support website: (https://support.microsoft.com/en-us/help/321686/how-to-import-data-from-excel-to-sql-server). My table name and filename are different, otherwise I am using the exact code below. I receive the error: The OLE DB provider "Microsoft.ACE.OLEDB.4.0 has not been registered." I've tried other OLEDB versions to no avail. Not sure how to check which version of the driver I need. The SQL server that I am working with is 64 bit but my local machines are 32 bit and I think this is causing issues. If anyone can help simplify this issue and point me in the right direction I would much appreciate it. I am well versed in VBA with some SQL background. Other than that I don't have much programming background. Thank you!
SELECT * INTO XLImport3 FROM OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0',
'Data Source=C:\test\xltest.xls;Extended Properties=Excel 8.0')...[Customers$]
SELECT * INTO XLImport4 FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=C:\test\xltest.xls', [Customers$])
The query:
SELECT * INTO [TableName]
FROM OPENDATASOURCE( 'Microsoft.ACE.OLEDB.12.0', 'Excel 12.0 Xml; Database=' + [SpreadsheetFullPath] + ';IMEX=1'' )...[' + [WorksheetName] + '$]'
Notes:
Keep in mind that the query is executed on the SQL server so [SpreadsheetFullPath] is the path on the server and not the local machine.
UNC paths (\\sharedDir\...) are accepted.
Keep Excel worksheets to be imported simple.
When something fails, the errors returned by this driver are very unhelpful, so try to avoid them by observing 3.
You may need to install drivers on the database server: Office 2010, Office 2016
There is a bigmuscled engine called SSIS (Sql Server Importing Services) that does this, with error reporting, transformation of data, scheduling etc. It may already exist on your server. This is not the place to describe it in detail but there are tutorials on youtube. During the years the design environment has either been standalone or a plugin in Visual Studio.
It will sure solve your importing problems, but there is a (steep) learning curve. (Which may pay off in you increased skills!). After SSIS you can continue to SSRS and SSAS but that is another story!
Your current problem is the driver name in the "connection string". It often depends on your server's OS-version. (I.e. what has (not) been installed). Instead of guessing (as I have done, developing on XP and at first deploying blindly on Win7 and Win10), I suggest you ask your Admins to on your server make a ODBC connection DSN file connecting to that Excel file of yours, and then look at the contents of that DSN file. It will contain the connection string and the driver name you are looking for, that suits your server's installation. I have also found that "default port#" may suddenly be required in the string as well when connecting to Sql Server.
Disclaimer: I am somewhat of a n00b when it comes to database programming, so bear with me.
I've been attempting to batch process a rather large amount (~20 gb) of data all contained in .MDF SQL database files. The files contain meteorological data obtained through weather balloons, with each table consisting of ~1 second observations of winds, pressure, height, temps, etc, and are created with our radiosonde tracking software on an unnetworked Windows machine. It is possible (and quite easy) to load the files using the associated software and export the tables as an ASCII text file...however, this process involves manually loading each one. As I'm performing a study that requires as many soundings as possible (we have over 2000), doing this process over and over for several years of twice-daily observations is extremely time-prohibitive.
I've been taking the files off of the computer and putting them on my laptop running Linux Mint, and consider myself to be fluent with Perl...I do most of my data analysis with Perl scripts. That said, I've had the darndest time trying to get into the database files!
I've tried to connect to one of the files using the DBI package using variants on
$dbh = DBI->connect("DBI:ODBC:$filename") or die "blahblahblah";
I have unixODBC installed and configured, have downloaded "libmyodbc.so" and "libodbcmyS.so", and keep getting the error
DBI connect('','',...) failed: [unixODBC][Driver Manager]Data source name not found, and no default driver specified (SQL-IM002) at dumpsql.pl line 6.
I've tried remedying this a number of ways over the past couple days, and I won't post them here for the sake of brevity. My odbcinst.ini file is as follows:
[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so
Setup = /usr/sib/x86_64-linux-gnu/odbc/libodbcmyS.so
FileUsage = 1
I'm seriously confused. I THINK I'm doing everything that various online tutorials are suggesting, but everyone else is connecting to servers and these files are all local and in the same directory! Could anyone attempt to point me in the right direction? All I want is to calculate meteorological values using vertical sounding data! Am I missing something totally obvious?
Any help would be greatly appreciated!
It seems the original database server was a Microsoft SQL Server (MDF files). I am afraid these files alone are useless on a Linux machine. You need a Microsoft SQL Server on a Windows machine to get access to the contained data.
You described that you are able to attach a MDF file on a SQL server manually and then you can export the needed data as text files. Try to automate that. I'm not a MS SQL Server expert but it should be possible.
E.g. here is a tutorial to attach and detach a MDF file via T-SQL. So my approach would be to write a script which iterates over the 2000 MDF files and attach each to the SQL server. Then execute a query to export your data and then detach the MDF.
I am having trouble gaining access to FileMaker Pro 11 data through the ODBC connection and starting to believe that it is not possible.
I have installed the odbc drivers supplied with the installation (11.03.76.00) locally to the FileMaker database, having worked out that they will not work remotely to the server. Have setup and successfully tested a system DSN.
When I try to use that System DSN within SQL Server or SSIS (same underlying process), I am gaining access to the list of tables and can preview the data, however when each process tries to get the metadata regarding the tables it fails.
SQL lets me select the tables / columns, preview the data, match it to destination and change the data types, but then fails on the next step of checking the conversion
SSIS provides list of tables / columns, data preview, but fails to list the columns (im guessing because it cannot work out the types)
FileMaker tech support does not cover the ODBC driver which has led me to believe it does not work...
Has anyone successfully attached to FileMaker Pro though the version 11 of the driver with SSIS or SQL? I need to automate a daily extract - any other ideas?
As billinkc points (above comment - sorry cannot convert comment into an answer), you can use the Script component as a Source and program around the ODBC driver issues.
The FileMaker Pro 11 odbc driver is data type aware, but they are not plumbed in correctly. The work around requires converting each column to string and then TryParse'ing to the correct data type.
Problem: Could not find installable ISAM
I am executing a query from MS Access in order to pull information from MS SQL Server 2005.
When I attempt to open a linked ODBC connection to the table directly it opens with no issues. However, when I attempt to create a DSN-less connection, I receive an ISAM error.
I have the following error when I attempt to execute my SELECT query:
"Could not find installable ISAM."
The code I'm using is as follows:
SELECT * FROM [Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].[My_View_Name]
The help from MS Access provides the following information:
Could not find installable ISAM. (Error 3170)
The DLL for an installable ISAM file could not be found.
This file is required for linking external tables (other than ODBC or Microsoft
Jet database tables). The locations for all ISAM drivers are
maintained in the Microsoft® Windows® Registry. These entries are
created automatically when you install your application. If you change
the location of these drivers, you need to correct your application
Setup program to reflect this change and make the correct entries in
the Registry.
Possible causes:
+ An entry in the Registry is not valid. For example, this error occurs if you are using a Paradox external database, and the Paradox
entry points to a nonexistent directory or driver. Exit the
application, correct the Windows Registry, and try the operation
again.
+ One of the entries in the Registry points to a network drive and that network is not connected. Make sure the network is available, and
then try the operation again.
I have also found KB articles from Microsoft explaining when and how this should be handled. However they are unclear to me if they are actually rooted from another type of issue.
For example:
283881 and 209805 Tell me the purpose of ISAM is to tell how to format data other then, MS Access' native formatting. (But I don't want to format it in another way and the other formats do not list what I think to be the appropriate format-er)
and, 90111 Tells us the driver in the .ini file may be pointing to the wrong place in MS Access 2.0 which no longer exists in version 97+.
The odd thing is I have a DNS-less setup for another table which works fine. The only difference I see here is the default naming of the database object is not standard, so possibly I am not referring to the schema correctly in my syntax.
What am I doing wrong here? Is it truly a syntax error?*
Are there any "View" permission considerations which need to be made on the server end?
Try adding ODBC; at the start of the connection string and remove the brackets around the view name:
SELECT * FROM [ODBC;Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].My_View_Name