I have an application that uses an access 2000 database currently in distribution.
I need to update one of the recordsets with additional fields on my customer's computers.
My data controls work fine as I have them set to connect in access 2000 format. But, when I try to open the database in code, I get an unrecognized data format error.
What is the best way to replace or add to the database on their machines?
It is possible to update an Access database using VBScript, ADO and DDL.
strCon="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=Example.mdb;" _
& "Jet OLEDB:Database Password=pass;"
Set cn=CreateObject("ADODB.Connection")
cn.Open strCon
strSQL="ALTER TABLE Example ADD COLUMN Example Text (20)"
cn.Execute strSQL
More connections strings: www.connectionstrings.com
I much prefer using DAO collections to updating BE database schemas as it gives you much more control over what you can do. For example you can easily delete or create tables, records, indexes and relationships. See the TempTables.MDB page at my website which illustrates how to use a temporary MDB in your app and has sample code to get you started.
Related
I have an Access 2019 front-end database that links to a SQL Server 2017 Express database.
I'd like to export a table or query from the VBA code in the front-end into an Access (Jet) format database (as a portable data format to use for updating a remote site)
The code I've tried (for a table called FileLocation) is:
Access.DBEngine.CreateDatabase "C:\Temp\ExportTest3.mdb", DB_LANG_GENERAL
docmd.TransferDatabase transfertype:=acExport, databasetype:="Microsoft Access",databasename:="c:\temp\ExportTest3.mdb", objecttype:=acTable, source:="FileLocation", destination:="FileLocation", structureonly:=false
This "works" but the table created in the ExportTest3 database is a link to the SQL database (with the Connect property set in MSysObjects) so is dependant on the SQL Server connection, but I'm looking for an independant portable .mdb file that can be read on any PC.
Edit: I've discovered that I can use
docmd.RunSQL "select * into FileLocationLocal from FileLocation"
and then use TransferDatabase to export the FileLocationLocal table as a non-linked table
But is there a way to do this as a single step, or is there a better approach?
Consider:
Access.DBEngine.CreateDatabase "C:\Temp\ExportTest3.mdb", DB_LANG_GENERAL
CurrentDb.Execute "SELECT FileLocation.* INTO FileLocation IN 'C:\Temp\ExportTest3.mdb' FROM FileLocation"
I am reworking old VB6 apps into VB.NET with Visual Studio 2005 and all of them suffer from the same problems.
One of those is, access the DB2 database by using an Access 2000 file which has links to the tables and second approach is, using ADODB.RecordSet with concatenated string SQL queries directly run on to the database.
I know I can use Linq which is the right tool for the job, but I don't have time to learn it at the moment. I have to finish this job quickly.
Examples:
Function selectNA_FromMyTable_ByNA(ByVal na As String) As String
Dim sql As String = "SELECT na FROM DB2Scheme.MyTable "
sql = sql & "WHERE (na = '" & na & "')"
Return sql
End Function
and
Function selectNA_FromMyTable_ByNA(ByVal na As String) As String
Dim sql As String = "SELECT na FROM DB2Scheme_MyTable "
sql = sql & "WHERE (na = '" & na & "')"
Return sql
End Function
where DB2Scheme_MyTable is link to DB2Scheme.MyTable table.
I don't like mixing approaches although they both work properly.
Which is better approach?
Which approach would be better for debugging? For example, how can I detect that the user using the application does not have privileges to write or read data from a certain table in the scheme?
well certainly eliminating the Access database would be ideal. i assume in the prior model, the Access database also served as the front-end? if you're moving to .net, then i don't see the point in keeping the access database. go directly to the db2 database, just be mindful of the database drivers that may need to be installed when distributing this app. less of a problem if its a web app.
generic error handling in .net should reveal if users have access issues. you may want to check that up front when your application is launched if your application is going to use the users credentials, and not a user id of its own to access the database. I am not sure this should be something of a concern when rewriting the app, are you not using the same authentication, or logon credentials used in the formal app?
I'm making my first report with Sql Server Reporting Services (2012) and have managed to create two datasets successfully, each one connecting to the same Data Source. This Data source uses an embedded connection and the user can select the server and Database at runtime. The connection string is as follows
="data source=" & Parameters!ServerName.Value & ";initial catalog=" & Parameters!DatabaseName.Value
The two parameters in question are created and everything works fine for these two datasets, the report displays with a choice of servers and databases and displays the relevant data when I click on Show Report.
However, when I try to add a third DataSet (I need a separate SQL command to pull separate data for the footer and header) this one doesn't connect.
I've tried the following:
-Right click on the existing data source to create the data set, selecting the existing source. When I open the query designer it fails to connect
-Create a new data source with a fixed connection string. This works but is not what I want
-Create a new data source with another name and the same connection string as the original. This fails, and is not really what I want anyway.
Is there anything obvious I'm overlooking? For info, I originally had the first two data sets created and running with a fixed connection string before I changed the connection string in the data source to use a dynamic one. I've restarted the report designer since, though, and the first data sets continue to connect using the dynamic string. I tested with multiple databases just to be sure
Never done this before myself but the last 2 sentences in the section Expression-Based connection Strings msdn.microsoft.com/en-us/library/… looks to me like you need to revert to a fixed connection string to do your update then change back to dynamic when ready to publish?
We have an app we maintain which is written in VB6 and uses the prehistoric DAO technology to do its database access. The database is in Sql Server 2008.
We are writing a new module now, that I wanted to logically separate off with its own schema. However when I try to write a simple select query like:
SELECT ROWID, NAME FROM exports.TYPES ORDER BY NAME
DAO is complaining:
Error # 3024
Couldn't find file 'C:\Program Files\Microsoft Visual Studio\VB98\exports.mdb'.
So clearly, DAO is interpreting the schema as a different database... is there any way to tell it to just pass the query through to the Sql Server?
This app is NOT using Access at all, just the DAO libraries.
Grrr... after googling for a half-an-hour, and then finally deciding to post a Q, then I try one more google and find the answer. Sheesh! I hate when that happens!
Anyway, here is the answer for those who may need it in the future.
I had to change my OpenRecordset statement from this:
Set rs = db.OpenRecordset(SQL, dbOpenSnapshot, dbSeeChanges)
to this:
Set rs = db.OpenRecordset(SQL, dbOpenSnapshot, dbSeeChanges Or dbSQLPassThrough)
Answer is from this KB on ms.com.
How do I get ms-access to connect (through ODBC) to an ms-sql database as a different user than their Active Directory ID?
I don't want to specify an account in the ODBC connection, I want to do it on the ms-access side to hide it from my users. Doing it in the ODBC connection would put me right back in to the original situation I'm trying to avoid.
Yes, this relates to a previous question: http://www.stackoverflow.com/questions/50164/
I think you can get this to work the way you want it to if you use an "ODBC DSN-LESS connection"
If you need to, keep your ODBC DSN's on your users' machines using windows authentication. Give your users read-only access to your database. (If they create a new mdb file and link the tables they'll only be able to read the data.)
Create a SQL Login which has read/write permission to your database.
Write a VBA routine which loops over your linked tables and resets the connection to use you SQL Login but be sure to use the "DSN-Less" syntax.
"ODBC;Driver={SQL Native Client};" &
"Server=MyServerName;" & _
"Database=myDatabaseName;" & _
"Uid=myUsername;" & _
"Pwd=myPassword"
Call this routine as part of your startup code.
A couple of notes about this approach:
Access seems to have an issue with the connection info once you change from Read/Write to Read Only and try going back to Read/Write without closing and re-opening the database (mde/mdb) file. If you can change this once at startup to Read/Write and not change it during the session this solution should work.
By using a DSN - Less connection you are able to hide the credentials from the user in code (assuming you're giving them an mde file you should be ok). Normally hard-coding connection strings isn't a good idea, but since you're dealing with an in-house app you should be ok with this approach.
I think you'd have to launch the MS Access process under the account you want to use to connect. There are various tools that let you do this, such as CPAU. This tool will let you encrypt the password as well.
We admit here that you are using an ODBC connexion to your database with Integrated Security on, so that you do not have/do not want to write a username/pasword value in the connexion string (which is according to me the right choice).
In this case, there is fortunately no way to "simulate" another user when connecting to the data. Admit with me that being able to make such a thing would be a huge break in integrated security!
I understood from your previous post that you wanted users to be able to update the data or not depending on the client interface they use. According to me, the idea would be to create for each table a linked 'not updatable' view. Let's say that for each table called Table_Blablabla you create a view (=query in Access) called View_Table_Blablabla ...).
When using Access, you can then decide at runtime wether you want to open the updatable table or the read-only view. This can be done for example at runtime, in the form_Open event, by setting the form recordsource either to the table or the view.
#Philippe
I assume that you are using the word admit as being roughly equivalent to understand or perhaps agree; as opposed to the opposite of deny.
I understand the implications of having all the users login to the database using one ID and password (and having them stored in the application). That to me is a smaller risk than the problem I'm facing right now.
#off
Some more background to the problem:
I have ODBC connections set up on each of the users workstations using Windwos NT authentication. Most of the time the users connect using an MDE setup to use that ODBC connection - in this case they ALWAYS have the ability to add/update/delete data.
The problem comes that some of the users are educated enough about MS-Access to create a new mdb and link it to the MS-SQL server. They can then edit the data right within the tables rather than going through the application which does a certain amount of validation and hand holding. And they like doing this, but sometimes the mess it up and cause me problems.
What I was hoping to do (which I just experimented with) was to refresh the links to the database something like this for each table (Note: I've switched the ODCB connection to SQL Server authentication for this experiment, and added the accounts to the SQL server as well: readonly - which can't to any updates, and readwrite - which has full privileges on the table).
myTable.Connect = _
"ODBC;" & _
"DATABASE=" & "MyTestDB" & ";" & _
"UID=readonly;" & _
"PWD=readonly_password;" & _
"DSN=" & "MyTestDB" & ";"
myTable.RefreshLink
this stops them from editing, but I can't get a later readwrite to work
myTable.Connect = _
"ODBC;" & _
"DATABASE=" & "MyTestDB" & ";" & _
"UID=readwrite;" & _
"PWD=readwrite_password;" & _
"DSN=" & "MyTestDB" & ";"
myTable.RefreshLink
It seems that whichever permission I connect with first, sticks permenantly. If I started readwrite and then go to readonly, the table remains with the readwrite privileges
Why not use integrated/windows security. You can grant an active directory group the rights you want the users and then add the users accounts to that group. I believe you can also use sql server's roles feature in addition to this to limit functionality based on the client application being used.