I need a data store for single-user, read-only access. I need multiple tables, but not related. I also need to do two-column indexing. Seems like Jet is a good choice. Front end will be either VB or C#. The data is not user-entered data, but meta data about users and external files. What are the deployment issues for Jet -is it built into all Windows OS versions from xp onward? I plan on including the Access Database in the resource file.
MS Jet 4.0/DAO 3.6 are part of the operating system and are in Windows 2000, XP, Vista and Windows 7. They are updated by Windows Update and the security patches are applied as appropriate.
Alternatively to including the MDB file in the resource file you could build it if it isn't present. See the TempTables.MDB page at my website which illustrates how to use a temporary MDB in your app.
You can also use the Compare'Em utility
to keep the database files tables, fields, indexes and relationships updated as you upgrade your app.
See why-should-i-use-sqlite-over-a-jet-database, and try both.
The Microsoft Access .mdb driver is included with XP and up. It's part of MDAC.
There are a few other options for this, by the way. Look into SQL Compact, VistaDB, and SQLite.
Be aware that currently there are no 64 bit versions of the JET engine included with the operating systems!
The engines for 64 bit will be available with next Office. Beta can be downloaded from Microsoft Downloads
If you Google this you will see that Jet is no longer a standard part of Windows and has been deprecated. The ACE driver that is now part of Office 2010 does support MDB files, though Microsoft emphasizes that it is not a replacement for Jet. They want you to use SQL Express instead.
You can download and install the ACE driver separately, but note that for no sane reason you can not have the 32 and 64-bit versions of it installed on the same machine. If oyu have Office 2007 32-bit installed and you try and install the 64-bit ACE engine, it gives you this big dialog box that tells you you have to uninstall Office 2007 first.
We switched to sqlite. No more such hassles.
Be careful when using the CSV ODBC driver, there is a bug I discovered.
If you export an MS-Excel file to CSV format, you get double quoted text strings if the text string exported contains double quotes or commas embedded within it.
Example:
"Hello World", This is Eric.
exports as
"""Hello World"", This is Eric."
However, if you read in this data to an ODBC enabled program, then export the data back out, what happens is that the CSV ODBC Driver puts double quotes around text whether the text has embedded double quotes and/or commas, or not.
The huge problem with this is that you cannot run a FILE COMPARE on the original file exported from MS-Excel, and the newly created file (read in then output) from an ODBC enabled program using the CSV driver.
You will always get a FAILED FILE COMPARE (checksum) because the data is not equal. That really screws up QA/QC.
Also, another huge bug exists in ODBC Administrator
whereby you cannot edit the files the Text Driver recognizes/supports.
If you edit that entry, Chinese characters are stored in the Windows Registry. But it is a nice way to parse CSV data via ODBC instead of having to write your own code to strip out the extra Double Quotes.
Related
The FoxPro ODBC on my machine is only able to connect to certain tables in the ODBC Connection. When I try to connect to specific tables in the same connection I receive the error [Microsoft][ODBC Visual FoxPro Driver]Not a table.( #123). However, I am successfully connected to other tables without an issue. I know these tables I am unable to connect to aren't corrupted because I am able to view the data in them using Visual Fox Pro.
Any suggestions would be appreciated.
First I'd use the Visual FoxPro OLEDB driver instead of ODBC. It's faster and more fully featured.
Then check whether the TableValidate setting is affecting it. To check that, back up the data then open the table exclusively in Visual FoxPro and issue the following in the command window:
append blank
go bottom
delete
pack
This will append and then delete a blank record, forcing the header counters to be recalculated. Then try it via the connection.
Also try turning tablevalidate off for the OLE DB driver as follows.
Create a text file called CONFIG.FPW in the same location as vfpoledb.dll, on a 64-bit machine this will be in 'C:\Program Files (x86)\Common Files\System\Ole DB'.
In the text file just put one line:
TABLEVALIDATE=0
And retry.
First: Do not use ODBC driver UNLESS your tables are VFP6 and earlier compatible. The last ODBC driver released was only for 6 and earlier. If you still need to use ODBC then check Sybase ADS driver. It is compatible with later versions too and local mode is for free.les
Second:Be sure that the tables you are trying to open are really not corrupted (not a table error is often occurs when the header info is off by pne record = you can check the details on "Not A table" entry on foxwikis. You might be looking into two different files when you check from VFP and through OLEDB driver. You can specify the fullpath to be sure.
I have an Access 97 database that serves as a front-end, via ODBC and linked tables, to a MySQL database, running under Wiin7-64. (Yes, it does work!) The database contains info about places of worship and pilgrimage in the part of France where I live. In addition, I have tens of thousands of photos of the sites in Photoshop Elements 9. The underlying database engine of PSE9 is SQLite, and interesting data about the photos is there (titles, which ones I like, etc.). I would like to link from Access to the tables in the SQLite database as I do to the MySQL database.
My problem: I am unable to create an ODBC connection to the PSE9 SQLite database. I have done multiple searches via Google, read multiple posts at stackoverflow and elsewhere, tried various suggestions, and still no ODBC connection, neither in the 32bit or 64bit ODBC tools of Win7-64. I'm stumped.
So far, I've
downloaded sqliteodbc.exe from http://www.ch-werner.de/sqliteodbc/ and run it (multiple times)
copied sqlite3odbc.dll, sqlite3.def, sqlite3.dll, and sqlite3.exe to the \windows\system32 folder
entered this command at the Windows command line: "rundll32 c:\windows\system32\sqlite3odbc.dll,install", which produced this error message "Copy c:\windows\system32\sqlite3odbc.dll to c:\windows\system32\sqlite3odbc.dll failed."
When I look at the ODBC and ODBC (32-bit) windows, I don't find a User DSN, System DSN or File DSN for SQLite. Any suggestions?
Thanks,
Harvey in balmy Bordeaux
Whats with all that copying dlls around - you don't need to do any of that. Just download the 32 bit version and double click on it - the driver will be installed. Then find the 32 bit ODBC Administrator (note there are 2 on 64 bit windows and only one is 32 bit), fire it up and create a DSN. You should see sqlite3 in the drivers tab.
DSNs are not there automatically, you have to create them yourself. There should be an "Add" button in the ODBC administrator. Then you select the type of driver "SQLite", and then configure the details in the next dialog.
A DSN normally contains all the configuration information needed to connect to a specific database instance so that all this - which may be different from one database system to the other - can be referenced by one name. That is where the name "Data Source Name" comes from.
I am writing an application in C# (.NET 4.0) which has to integrate with another, much older application. Part of the requirement is that my program must read data from three Btrieve files. I can assume that these Btrieve data files will already exist on the computers where my program is installed, and I can also assume that Pervasive PSQL V9 will also be installed and the relational and transactional service programs are running.
I have the associated DDF files, and I can install them as part of my application. The way they were created I have to put them in a different directory to where the Btrieve data files are. (They have to be a sub-directory of the directory where the data files are).
I didn't know anything about Pervasive or Btrieve when I started, but after a bit of experimentation I have got to the point where I can create a DSN using the 32 bit ODBC administration tool, and I can read from the data files using the ODBC ADO connector. All good so far.
My question is, is it possible to read from these files from my .NET program without having to create an ODBC DSN on the machine? In other words, is it possible to specify the directory where the *.DAT files are and the directory where the *.DDF files are in the ODBC connection string?
I'm not committed to using ODBC, I'm happy to use OLEDB or any other technology that allows me to reliably read from these files using .NET.
While a DSN-less connection allows your to connect without a DSN, you would still need a Database Name. Pervasive Database Names can be created on the fly using DTI or DTO. Using C#, I would suggest DTO.
If you can't create a Database Name, you can use OLEDB. It supports using a path in the Data Source parameter of the connection string as documented in the Remote Connections section of the OLEDB documentation.
One more caveat, make sure to compile your .NET program as x86 and not AnyCPU. The Pervasive OLEDB provider is only 32 bit. If you install your app on a 64 bit Operating System compiled as AnyCPU, it will look for a 64 bit provider and fail.
You should search for DSN-less connection. Instead of passing DSN=mydsn to the connect method (where mydsn is the DSN you set up) you pass DRIVER=xxx (where xxx is the name of the driver) and any other attributes it needs to direct it at the files. There are loads of sites with lists of connection strings for different ODBC drivers so one is bound to list Pervasive if you cannot locate the documentation for your ODBC driver. Another alternative to so look at your DSN in the registry where you'll find the names of the attributes you need to specify.
i am tring to read excel file but the iis7 is giving this error:
"Microsoft Office Excel cannot access the file 'D:\Demosites\Domaininterface\Keywordsfolder\keywords2172011 23841 PM.xlsx'. There are several possible reasons: • The file name or path does not exist. • The file is being used by another program. • The workbook you are trying to save has the same name as a currently open workbook."
someone know about this?
Since the path is explicit, it sounds like a permissions issue - simply: the account that the application / app-pool is running as (in IIS) doesn't have access to that folder.
However, unless it has changed recently, you should note that Excel is not supported for use on a server - it is desktop software, and you may run into a multitude of issues using it on a server. And I have no idea whether this would be a licensed scenario ;p
I've tried passing binary SQLite DBs over the network between different OSes and architectures - it didn't work.
What format are you all using? I've tried an unholy hack of copying SQLite's shell.c and calling shell_main() with a hacked up argc, argv, stdin with success on Mac. Pity I'm developing for the iPhone and it fails only there.
Does everyone do such awful things?
This is one of the core features of SQLite.
Stable Cross-Platform Database File
The SQLite file format is cross-platform. A database file written on one machine can be copied to and used on a different machine with a different architecture. Big-endian or little-endian, 32-bit or 64-bit does not matter. All machines use the same file format. Furthermore, the developers have pledged to keep the file format stable and backwards compatible, so newer versions of SQLite can read and write older database files.
Most other SQL database engines require you to dump and restore the database when moving from one platform to another and often when upgrading to a newer version of the software.
http://sqlite.org/different.html
Check the code that's passing the databases. Do a byte-by-byte comparison to make sure they're equal after transfer. This definitely should be working.
Beyond Compare has good binary file comparison support.