I'm trying to rebuild an Access adp application in Access 2007. I started with a blank database, linked the SQL Server tables I need with ODBC, and then copied over all of the forms from the original application. I then updated the data sources for the forms to go to the correct tables.
When I open one of the forms, I get the error "Syntax error in WITH OWNERACCESS OPTION declaration". This error is occurring before the Open event code is being run.
Does anyone have any ideas about how to track down where this error is coming from? Or maybe an idea of another way to do this altogether?
Thanks!
WITH OWNERACCESS OPTION makes no sense in an ADP, as it's a command for Jet SQL for use with Jet user-level security. With an ADP, the security should all be set on the server. So, you should remove all the WITH OWNERACCESS OPTION statements from your form RecordSources.
Frankly, I'm not sure they have an effect in anything other than a saved QueryDef, so likely they were an error in the original application.
Also, I would never recommend copying anything from an MDB into an ADP. First off, I don't believe migrating to an ADP is ever advisable (though I certainly use ADPs as an administrative tool with my MDB/ODBC apps that use SQL Server), but secondly, there are so many differences between the two platforms that I just can't see them working.
If I chose to migrate an MDB to ADP (and I can't imagine that I ever would, given that MS has been deprecating ADPs for about half a decade now), I would start from scratch and rebuild it from the ground up.
Related
I'm updating a 2006 program written in VB6. It has a large database created with Access 1997 with which the program works fine, but Access 2007 would not allow me to modify the database unless I converted it from .mdb to .accdb.
I did so and in Design mode, changed the DatabaseName to the .accdb extension, left RecordsetType as Dynaset, but when I click on RecordSource, I get an "unrecognized database format" message.
I've researched everything I could find on the web. Someone said to switch from DAO to MS Office Access database engine (12.0) which I did. Someone else suggested using Access (2007) to compact and repair it, which I did.
In Resources, I see *MS ActiveX Data Objects 2.5 library and MS Data Environment Instance 1.0 (SP4). I don't know what they are for offhand, not having looked at this software in a dozen+ years.
If I run it without specifying a RecordSource in Properties, when it gets to the line:
Set rs_BidTable = db_BidBase.OpenRecordset("Table1") (where Table1 is a table in the database)
it gives a "Type mismatch" error message. None of the code changed after the update other than changing the database name in the code.
I could give more detail about what I have in the code, but since it's bombing in Design mode, I'm don't think the code is relevant (is it?).
I have other programs with databases updated to Access 2007 and never had this kind of problem.
I have a MDB database with plenty of VBA code, there are also connection strings to database. I need to have both the connection strings hidden, and the VBA code unavailable. In general I need to disable all functionality that is granted through shift-clicking the database file.
I tried making an MDE but it seemed to have no actual impact even though no errors were thrown, the MDE is exactly as accessible.
Thanks!
In addition to creating an MDE, you can:
disable shift-clicking
hide the database window
(this link shows how to do it manually in the options - it's also possible with VBA, but I can't find an example right now. I can look tomorrow if you're interested)
At work, we have a "publish" process where we create an MDE and do the things linked above.
EDIT:
Creating an MDE is a realistic way to prevent access to the VBA code - MDEs contain no code and you can't edit forms and reports.
The only thing you can do in an MDE is opening the database window and view/edit the tables. But you can kind of prevent that by disabling shift-clicking and hiding the database window (see my links above).
Note that it's still possible to link the tables in another MS Access database and view/edit them. So there's no 100% proof way to secure anything that you put into a table.
But when you put the connection strings into the VBA code and completely remove the code by creating an MDE, it's not possible to get the connection string out of the MDE.
I have an application that creates an Jet database at run-time, and imports ~100k records so that I can make use of the indexing for performance reasons (1 minute versus nearly 10 when not using a Jet database).
The database is created using ADO Extensibility in Excel, and everything works just fine. However, my issue comes whenever I then open the MDB file in Access front-end, it automatically starts to "repair" the database.
The data is still fine after the "repair", however my main output query can not then be viewed in Access as it tells me it cannot represent the joins, and if I then view it in SQL the required joins are not there, and the query can no longer run. This still happens if I let it get "repaired" but do not open that query, i.e. it is the "repair" that breaks the query, not the act of trying to view it in Access. The funny thing about this is that I used the Access GUI query designer to construct the SQL as my life is too short to worry about it's crazy bracketing style, but it then later decides that it's too complex for itself??
Also, nothing else appears to be affected so I can only assume it's this one query it doesn't like.
This isn't a deal-breaker for me as my fix is to make the MDB hidden and advise users who can see it not to open it.
However, I would really like it if the database could be opened and I didn't have to hide it away like that. Therefore, my question is whether there is any way to prevent the MDB being "repaired" automatically?
Thanks!
Microsoft Access is "repairing" the file when opened because it is missing some tables that are specific to the Microsoft Access user interface. Since you created the MDB file directly using OLEDB with Microsoft.ACE.OLEDB.12.0, these tables are not present, and must be created when Access opens the MDB the first time. There are several ways you can circumvent this:
1) Name the MDB something other than .mdb - e.g.: MyAccessDatabase.mad - this will prevent Windows from using Microsoft Access to open the file.
2) Use COM+ to open an instance of Microsoft Access, and have it create the .MDB file. This .MDB file will then have all the necessary tables present and will not need to repair the file.
FYI, whenever Microsoft Access opens an MDB that needs repairing in this fashion, it will inspect all the QueryDef objects for invalid SQL and correct them as necessary. This is why your "complex" query is breaking.
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.
I'm using the Access Developer Extensions to attempt to source control this access database in TFS, however, I'm not sure I am doing it right. I can add a .mdb to source control and create a database from that source control.
I'm probably making a stupid mistake, but I can't figure out how to close the database I created from source control and reopen it while it's still under source.
Does anyone know of any tips or guides on this? I've searched for help on Access Developer Extentsions but I haven't found much. Thanks in advance guys!
I think I found what I was doing wrong. My database automatically compacts on close, so when it tried to do this Access asked me if I wanted "to remove the compacted database from source control". I thought this meant it would just not store the .mdb file, but still keep the objects (like tables, vba, queries, forms, etc) under source. However, this appears to completely remove it... from MSDN:
"Changes to Microsoft Access Behavior
Using the Compact Database Command
In order to take a database that is under source code control and deliver it to a user, you need a way to cut the database's ties to source code control. When you compact a database that is under source code control, Microsoft Access 2000 prompts you to remove the database from source code control.
To remove the database from source code control, Microsoft Access simply removes the Visual SourceSafe properties from the Microsoft Access database and its objects."
http://msdn.microsoft.com/en-us/library/aa155494(v=office.10).aspx
When I said do not remove compacted database from source control, my database and it's objects stayed under source.