ALL,
Is there a query which will give me the version of the mdb/accdb file created?
Or this info is not stored anywhere?
Background:
I'm working on C++ program, connecting with ODBC driver and want to know ACCESS version behind this file.
TIA!!
Short answer: No
It has been requested from many to have an option to check if a database file supports, say, BigInt or DateTime2 but, currently, you are left with trial-n-error.
However, if you don't plan to modify the scheme, your only concern should be, if the database file is of the old mdb (JET) form or the newer (introduced 14 years ago) accdb (ACE) format.
You can easily obtain that information using DAO, the Database.Version property.
In vbscript, that'd look like this:
Dim dbe
Set dbe = CreateObject("DAO.DbEngine")
Dim db
Set db = dbe.OpenDatabase("C:\Path\To\Db.accdb")
WScript.Echo db.Version 'E.g. 14.0 for Office 2010
Using COM is a lot more verbose in C++ so I'll leave that to you, but the approach could be the same.
Using only ODBC, I'm not sure how to obtain this information, though.
Related
I was wondering if someone could explain the difference between an ADODB.Connection and creating an Oracle session through "OracleInProcServer.XOraSession". Is one better than the other in certain cases?
From what I have read in ADODB cnn.Open "Pubs", "MyUserName", "MyPassword" and OraSession you put in openDatabase(database_name, database_version, database_displayname, database_size).
How do the connections differ?
Also with the ADODB connection you can open a recordset and save with a rs.Open and a rs.GetRows. Is there a way to save the values of the query to then display in the Excel with the OraSession connection?
Dim cnn As ADODB.Connection
Dim rs As ADODB.Recordset
verses
Set OraSession = CreateObject("OracleInProcServer.XOraSession")
Set OraDatabase = OraSession.DbOpenDatabase("", "", 0&)
Thanks!
Maggie
Overall, both are tools to connect databases to programming environments. According to online docs, OracleInProcServer is an OLE Automation Object. Hence, after install it comes available as a VBA reference. ADODB (part of ADO) is a general database API and the other is a specific Oracle API. See further points below. Do note: I am not familiar with OracleInProcServer but below gathers from above source.
ActiveX Data Objects (ADO)
Generializable API: capable of swapping out connection strings and maintaining same consistent codebase across both OLEDB providers and ODBC drivers such as Oracle, MySQL, SQL Server, PostgresSQL, more; see example of MS Access and SQLite interchange;
Full-featured database API for working between application layer and backend database including calling stored procedures, action queries, working with recordsets, etc.;
COM or .DLL object not limited to VBA but any language that can make a COM interface (i.e,. Java, PHP, Python, R) as initialized with CreateObject("ADODB.Connection");
Since it integrates into a programming language, it can connect to the Excel object library (i.e., workbooks, worksheets, ranges), even Access/Word/Outlook/PowerPoint apps;
Microsoft is the vendor and maintainer; API is available for free download. However, usually no additional installation is required as ADO ships with MS Office software or Windows OS;
Widely known in the industry with time-enduring problem and solutions available in many tutorials, books, and online searches.
OracleInProcServer
Specific API: Customized and tailored solution specifically for Oracle (proprietary software) and no other database, so possibly is keen to Oracle-specific methods;
Appears to be a capable database API working with database, dynaset, and field objects;
COM or .DLL object not limited to VBA but any language that can make a COM interface as seen with initialization: CreateObject("OracleInProcServer.XOraSession");
Docs show dynasets can work with Excel workbooks, looping across records and fields (very similar to ADO) to display data:
'Display Data
For Rownum = 2 To myDynaset.RecordCount + 1
For Colnum = 0 To fldcount - 1
ActiveSheet.Cells(Rownum, Colnum + 1) = flds(Colnum).Value
Next
myDynaset.MoveNext
Next
Oracle is the vendor and maintainer and installation (possibly paid) is required; maybe it is installed with Oracle client and other components; plus users may be able to call someone for help with this product (check service agreement/terms);
Likely a small user base that may not have sophisticated issues resolved or solutions widely known or available.
Which one is better? This ultimately comes down to your preference or project needs. For simple tasks of connecting to database, calling queries, and outputting to Excel any above will do.
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.
I'm very new to visual studio and visual basic.
I already studied the basics of visual basic so I tried stepping up a little and play with database in visual basic. I'm using visual studio 2010.
I first made an access database. I followed the instructions that I searched on the net on how to connect it to your visual basic program. Data>Show Data Source>Add Data Source> ...
But when I search on how to do it, I became really confuse because of these things:
Is vba and vb the same?
all the tutorials are for access but why do they still need to have a stringconnection when they already connect it using what I did?
they are searching for .mdb but the extension of my access database is .accdb?
they have an sql query for inserting the datas from the csv file but the pc that will be using the program don't have sql installed but mysql. Will it still work?
I'm still noob in these things so please if anyone can shed some light in these questions, thank you very much. >.<
VBA and VB 6.0 are almost the same. Main difference is that VBA is intended to be host in application like Excel, Word ....
BUT language you probably use with VS 2010 is VB.NET and that is something different. VB.NET is object oriented language which target .NET Runtime and Framewor. See Difference between Visual Basic 6.0 and VBA
Connection string is a string that specifies information about a data source and the means of connecting to it.
In .NET this describe (or can) path or location, provider, credentials and other informations. See MSDN Connection string in .NET
If I'm correct MDB is older format and ACCDB is format used by Microsoft Office Access 2007 and newer. Here is post how to connect to access db file: SQL connection string for microsoft access 2010 .accdb
But do you realy need to use acess database? There are better alternatives.
There is no need of real database engine for your scenario. You wanna to use standalone file as a datasource, dataprovider will be responsible for interaction with datasource. E.g. OleDB provider
I need to develop a service and install it into a w2003 box to read excel files a then process its info. The process is as follows, users will upload excel files using FTP and then my service must take those files, validate and then update a SQL Server DB.
The application runs fine on my computer but on the server it asks for the libraries but when I try to install the MS office 2003 Primary Interop Assemblies, system displays "Please install Microsoft Office 2003 before installing the product".
I'd prefer to stay away of any server upgrade as we should require OKs, etc.. so, is there a simple way to just read excel files without having to install any update in the server.
any comments are welcome.
Thanks,
m0dest0.
ps. using vb.net and vs 2008.
Using Interop on the server is NOT supported by MS - see http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757#kb2
Since Windows Vista MS introduced several security-related measures which prevent a Windows Service from doing "desktop-like" things... which means you would have to circumvent several security measures to get it to work (NOT recommended!).
To deal with Excel in a server-scenario there are several options (free and commercial) out there:
I can recommend Aspose.Cells and Flexcel... didn't try SpreadsheetGear but hear+read lots of good things about it...
Free options (though for the newer xlsx format only!) are for example OpenXML 2 from MS and EPPlus.
For a solution with nothing to install on any recent versions of Windows Server..... I'm not sure the exact VB.NET code, but you should easily be able to do this on any machine using the Microsoft OLEDB drivers that should be available on any recent version of windows server or can be installed from a free download off of the Microsoft website for very old versions of windows server. I'll try to pseudo code this, so you will have to adapt it for VB.NET. Note that in order to reference your fields by name, the first row of the selected area in the worksheet must contain the fieldnames in the column values. Otherwise you will simply have to use numeric values to index each returned field by column position.
Set objExcelConnection = CreateObject("ADODB.Connection")
objExcelConnection.Provider = "Microsoft.Jet.OLEDB.4.0"
objExcelConnection.ConnectionString = "Data Source=d:\path\to\excel\file\on\your\server.xls;Extended Properties=""Excel 8.0;IMEX=1;"";"
objExcelConnection.CursorLocation = 3
objExcelConnection.Open
sSQL = "select * from [worksheetname$]"
set rsWorksheet = objExcelConnection.Execute(sSQL)
do while not rsWorksheet.Eof
sValue = rsWorksheet("FieldName")
rsWorksheet.MoveNext
loop
rsWorksheet.Close
set objExcelConnection = nothing
I use the Excel Data Reader (http://exceldatareader.codeplex.com/) when I need to process Excel files. It handles xls and xlsx files without a hitch, and I've got it running in a few applications on a server OS. It saves each sheet as a DataTable object, and each "cell" in the DataTable corresponds to the Excel cell with the same address. Depending on how you set up your SQL server link, there might not be too much conversion required to dump the contents into the DB.
I'm writing a desktop application that uses the main access database that will be hosted on a central server, but there will be a laptop with the app on that has an offline mode so records can be created offsite. When the laptop returns I want it needs to be synced back to the main database.
Has anybody got any pointers on a way to do this, I've briefly read about JRO but is there an alternative / better method?
Originally, I was just going to write some custom code to do this, but thought I'd check to make sure there wasn't something already out there.
Jet Replication is a perfect solution for this kind of scenario, because you can use the simplest form of it, Direct Replication, and don't need to have any outside dependencies.
Assuming your server is named \HomeOffice\ and the database is named "MainDatabase.mdb" and is stored in the \AccessDatabases\ folder, you could use this code behind a command button to synchronize from the laptop to the server:
Dim dbServer as DAO.Database
Set dbServer = DBEngine.OpenDatabase("\\HomeOffice\AccessDatabases\MainDatabase.mdb")
dbServer.Synchronize CurrentDB.Name
dbServer.Close
Set dbServer = Nothing
Now, there's no error handling, and you haven't checked for conflicts, so you'd need to do more than that, but that would get you started with the basics.
See the Jet Replication Wiki for lots more information on Jet Replication.
Access (at least through 2003) has built in capabilities to replicate a database that would be far better to use than rolling your own.
Here's some documentation on that feature: Database Replication
MS Sync Framework could be the answer, but it's a bit tricky to set up... http://msdn.microsoft.com/en-us/sync/bb821992
There is the Microsoft Sync Framework that is compatible with ADO.NET and MS SQL Server / SQL Server Compact, but that's not a small component, more like a multi-component framework.