I have an access application developed on Windows 10 - Office 365. The application is split in a BackEnd database shared between different users. FrontEnds are on user's computers.
For some users all works fine. No problems are encoutered, but for two users (one on Windows 7 / Office 365 and the other Windows 10 Office 365 (!)) the application blocks when specific data entry forms are opened giving error 2105 (Can't go to record). For instance:
Private Sub btnAddPsnCmp_Click()
Dim success As Boolean
On Error GoTo err_handle
success = validateData
If success Then
Dim pId As String
pId = Me.IDPerson
If Me.Dirty Then Me.Dirty = False
DoCmd.OpenForm "frmPersonsXCompanies"
DoCmd.GoToRecord acDataForm, "frmPersonsXCompanies", acNewRec
' DoCmd.GoToRecord , , acNewRec
Form_frmPersonsXCompanies.IDPerson = pId
Form_frmPersonsXCompanies.personCombo.Enabled = False
Form_frmPersonsXCompanies.cmpnyCombo.Enabled = True
End If
I replaced DoCmd.GoToRecord , , acNewRec with DoCmd.GoToRecord acDataForm, "frmPersonsXCompanies", acNewRec directly from their pc, recompiled the code and it works. In other cases I had to change the DataEntry property of some forms to YES to make it work.
Is there no easier way to do this? How should I manage this with future versions of the application? On my computer I have no error at all so it is hard to imagine what problems will occur on other computers.
I double checked permissions on back end and on front end folder. Checked references are:
Visual Basic for Applications
Microsoft Access 16.0 Object library
OLE Automation
Microsoft Office 16.0 Access Database engine object library
I tried adding
Microsoft Visual Basic for Applications Extensibility 5.3
but it didn't change the issue.
Can anybody help? Thanks
Related
I have an access VBA script that exports to Excel. It opens the workbook, copies & formats the data and saves the workbook. It's worked for years. It worked on my old system with Office 13, and it works on my new system with Office 16. Now I'm trying to run this on another PC that was just set up - it has Office 13 installed, but may also have the Office 16 version installed that came with the new PC.
When I manually open Excel, Excel 2013 opens as it should. When my Access code runs and tries to open Excel, it seems to be going to the new version - and the code stops working, I think because the Office 16 account isn't set up and when Excel opens it goes to the Office 16 activation screen instead of opening the workbook.
The export macro code is
Public Function Export_data(Optional table As String, Optional opt As String = "")
Set wb_app = CreateObject("Excel.Application")
wb_app.Visible = False
wb_app.displayalerts = False
path = DLookUp("[report folder]", "folder")
If opt <> "" Then
FileName = path & "\" & opt & ".xlsm"
Set wb_obj = wb_app.workbooks.Open(FileName)
End If
The error occurs at "wb_app.workbooks.open" with the error "Unable to get the Open property of the Workbooks class." When I set .Visible to True and look at what Excel is doing, it's going to the activation screen for the Office 16 account.
How can I change the VBA code to direct it to the correct version of Excel?
You can specify the version by using the 2-digit office version at the end of the file, e.g.:
Set wb_app = CreateObject("Excel.Application.14") 'Office 2010
You can look in the registry under HKEY_CLASSES_ROOT to see what's available. Of course, you can query the registry using VBA if you want.
I have built an Access database that is shared on our company network. Most users on the network have Access 2010 installed but some have Access 2016. When the database has been opened by someone with Access 2016 and then subsequently opened by someone with Access 2010 they are getting an error message as the Microsoft Excel 16.0 Object Library is marked "Missing".
I can fix this temporarily by selecting the '14.0 library' but the error recurs as soon as it is opened in the later version again. Is there anything I can do to stop this from happening?
Thanks
You can use late binding, which helps you avoid the issue. Code with late binding works with any appropriate object library, whichever is available.
You need to change the object initializations:
Dim excelApp As Excel.Application
Set excelApp As New Excel.Application
To
Dim excelApp As Object
Set excelApp = CreateObject("Excel.Application")
Note that if you use late binding, intellisense will be unavailable. My usual practice is to develop using early binding, and change it to late binding as soon as it's finished.
Are you sharing an unsplit database or sharing the front end of a split database?
Access is inherently multi user, but one must distribute it correctly. The database must be split into 2 files (this is a feature in the ribbon) and then each user has their own front end file which links to the common single back end file.
Then there should be no changing occurring to references once they are set up for a user's environment.
I want to check wheather my database application is running in a fullversion MS Access or only with a viewer / limited MS Access.
The problem is that in a limited version a user can close the last form and then is not able to reopen any form without restart the whole application.
Private Sub Form_Unload(Cancel As Integer)
If LimitedVersion Then
Cancel = True
End If
End Sub
So the question is how to determine LimitedVersion ?
You can use:
SysCmd(acSysCmdRuntime)
It will return True for the runtime version.
However, I would never allow the last menu to be closed in an application. The people with a full version can open the application in a different way if they need access to design.
To simulate the runtime environment, you can use the /runtime switch:
For MS Access 2010, it would look something like this, note that the line break is for display purposes.
"C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE"
"z:\docs\demo.accdb" /runtime
I'm looking to split a multi-page access report up into individual pdf files based on a Customer ID and then saving those pdf files based on the Customer Name (or ID).
I've looked into 'printing'/'converting' the report into one massive pdf file and splitting it there, but some customer invoices span two+ pages, therefore splitting that one pdf file page-by-page doesn't work.
Any help would be greatly appreciated; if anyone needs more clarification on anything, don't hesitate to let me know.
This can be easy with Access 2007 (see note below) or later.
Open your report using the WhereCondition parameter to limit the record source to a specific customer.
DoCmd.OpenReport "rptFoo", acViewPreview, , "Customer_ID = 1"
Then use OutputTo to save it as PDF with a file name you supply.
DoCmd.OutputTo acOutputReport, "", acFormatPDF, "Spacely_Sprockets.pdf"
Close the report afterward.
DoCmd.Close acReport, "rptFoo"
You could create a procedure which opens a recordset for Customer_ID and Customer_Name data, then use those 3 commands with values from each row.
If your Access version is older than 2007, you'll have to tell us about the method you're using to create PDF files.
Note: For Access 2007, Office Service Pack 2 provides Built-in Save As PDF/XPS support.
PDF printing is available with MS Access 2010, for 2007, you can install an add-on from Microsoft : Print, share, and protect files in the PDF and XPS file formats
For versions prior to 2007, you can use :
Stephen LeBan's ReportToPDF consists of just two DLLs but only works with MS Access
CutePDF is free and easy to use.
PDFCreator is also free and can be fully automated with VBA (though I have not used it lately, I believe this feature is still available)
Any number of paid-for PDF creators.
The WHERE argument for OpenReport has been available since the 2003 version (also OpenReport 2010)
To print a report for all customers for version 2003, 2007 and 2010, you can loop through the relevant file and
Dim rs AS DAO.Recordset
Set rs = CurrentDB.OpenRecordset("SELECT DISTINCT CustimerID FROM Invoices")
Do While Not rs.EOF
''expression.OpenReport(ReportName, View, FilterName,
'' WhereCondition, WindowMode) -- 2010 has OpenArgs
DoCmd.OpenReport "Invoices",<..>,,"CustomerID=" & rs!CustomerID
''OutputTo or other relevant code
rs.MoveNext
Loop
Getting a PDF then depends on your version and the tools you have installed. If you are using PDFCreator or CutePDF, for example, you can use acViewNormal for the view. PDFCreator set up will allow you to assign a file name in advance, for CutePDF, you will have to fill in a file name. For Access 2007 and 2010, you can use OutputTo, as has already been mentioned, so acViewPreview is best.
To email a report for 2007 and 2010, you can use SendObject. For earlier versions, you will need quite a bit more code. The easiest option is probably to automate Outlook.
I have written an application in MS Access 2003. I can run this using Access 2010, however when I open the same 2003 application with the MS Access 2010 Runtime only, I can no longer use the Right Mouse Click in a continuous form (as I can with the full version) to filter by selection or to sort data etc. Has anyone else encountered this situation? Is this a purposeful design of Access 2010? If so, does anyone know why the Right-Click Content Menu is not working? Otherwise - is it a normal part of the Runtime 2010 and my application is the problem?
The Runtime unfortunately doesn't have context menu enabled, however, you can re-create some of it for your application.
For instance, in mine, I create a basic copy/cut/paste context menu like this:
'-----------------------------------------------------------------------------'
' General Clipboard context menu, the basis for all forms '
'-----------------------------------------------------------------------------'
Public Function CreateGeneralClipBoardMenu()
On Error Resume Next
CommandBars("GeneralClipboardMenu").Delete
Dim cmb As CommandBar
Set cmb = CommandBars.Add("GeneralClipboardMenu", msoBarPopup, False, False)
With cmb
.Controls.Add msoControlButton, 21, , , True ' Cut
.Controls.Add msoControlButton, 19, , , True ' Copy
.Controls.Add msoControlButton, 22, , , True ' Paste
End With
Set cmb = Nothing
End Function
Just call this code once at the start of your application and the context menu will be available everywhere.
The Need a list of msoControlButton Ids thread on MSDN shows how to similarly add Sorting and filter options.
The standard context menus do not work with the Access runtime version. I have seen this effect with Access runtime versions 2003, 2007 and 2010.