I currently have a 'Save Export' task that is saving a table (+1 million records) to an .xlsx file on a SharePoint folder via mapped network drive. I want to add the date to the file Excel file name.
Currently for Export-Excel Spreadsheet:
File Name is: U:\Reporting\Extracts\Excel_filename.xlsx
File format: Excel Workbook (*.xlsx)
Under Specify export options: I don't have anything checked.
With Date:
File Name is: U:\Reporting\Extracts\Excel_filename_mm_dd_yyyy.xlsx
File format: Excel Workbook (*.xlsx)
Under Specify export options: I don't have anything checked.
I would want the final file name to be: Excel_filename_09_18_213.xlsx
I don't want to use VBA because creating the .xlsx file takes over 4 hours. Export the table directly to the SharePoint folder is faster, but I need to update the file name with the current date. Could I create a macro that adds the date to the file name before it is posted to SharePoint? Is there a 'RunCommand' or 'RunCode' command that I could run that would generate the file name with the date?
I have tried the following for the file name, and they didn't work. I get "Failed creating file." "The specification failed to execute. Try re-creating the specification.":
U:\Reporting\Extracts\Excel_filename&(Format(Date()),"yymmdd"))&.xlsx
U:\Reporting\Extracts\Excel_filename%Date:~12,2%%Date:~4,2,%%Date:7~2%.xlsx
"U:\Reporting\Extracts\Excel_filename"&(Format(Date()),"yymmdd"))&".xlsx"
U:\Reporting\Extracts\Excel_filename_(Format(Date()),"yymmdd")).xlsx
Many thanks in advance.
I'd use VBA for this task. I wouldn't save it directly from Access onto Sharepoint folder however, I'd save it to a temporary location on the local disk and then copy it over - much quicker. If you are talking about pulling the data from a local Access file - then it shouldn't be taking 4 hours.
DoCmd.TransferSpreadsheet acExport,acSpreadsheetTypeExcel7, "myAccessTable", _
"C:\MyExcelExport_" & format(date(),"yyyy-mm-dd") & ".xls", True
on the macro line set destination
="C:\YourFolder\fileName" & Format(Date(),"ddmmyy") & ".xls"
Related
I'm having a problem with DoCmd.TransferText acExportDelim where it will export the desired file from my query, but it will not format the outputted file name as expected and it places the file one folder up in the selected folder path.
I do the entire export operation via a form. The user selects the folder path in the form, then the query ID, and the VBA code appends them together in the "FileName" parameter of DoCmd.TransferText acExportDelim like so:
DoCmd.TransferText acExportDelim, "Export Specification", "QueryName", "Me.FileLocationTextField.Value Me.QueryIDComboBox.Value .csv", TRUE
The above code will output the file from the query, but it will have a file name like "Me#FileLocationTextField#Value Me#QueryIDComboBox#Value". The file has the correct contents, it's just that the name is not the text that is stored in the Query ID Combo Box, which is what I would prefer.
The other issue is that the File Location is always one folder up in the folder path. So if the user selects "C:\Users\User\Documents\Exported Files\CSV Files" the file will be exported to "C:\Users\User\Documents\Exported Files".
I've tried setting the confirming the value of Me.FileLocationTextField.Value with a MsgBox and it is indeed showing the correct and full path before it is sent to TransferText acExportDelim. I've also tried several combinations of escape characters and concatenations for the FileName parameter but none have worked to get the file name or the folder path to work correctly.
I’m a newbie on here so please be gentle :)
My question is: can I get SAS (9.4 with PC Files Server) to trigger a function in MS ACCESS that imports .txt files that SAS spat out earlier?
Background: I have inherited an Access database (.accdb, using vers. 2010), which source data comes from SAS. Current method is that SAS spits out .txt files, which I (semi-manually) import into the database. Semi-manually in that there is a button/macro that imports the files but I have to open the database and press the button. I would prefer not to have to intervene at all.
I tried to skip the import of tables by using PROC EXPORT (and PC FILES SERVER) and later PROC SQL (with Access database assigned via libname) to push the data from SAS directly. However, compared to the old approach, after doing a compact and repair, the database is still about twice the size. I searched the net on how to avoid increase in size but found no answers.
I would therefore like to keep the method of SAS spitting out the .txt files but also have SAS trigger the Access function in the database that imports the files.
The button in Access activates this code:
Private Sub ImportSASDataButton_Click()
Dim Update As Byte
Update = MsgBox("Have you ran the SAS program that creates the text files?" _
, vbYesNo, "Check files have been created")
If Update = vbYes Then ImportTables
Me.CloseFormButton.SetFocus
Me.ImportSASDataButton.Enabled = False
End Sub
Which if “YES” activates this code (which is the function I wish to trigger directly):
Function ImportTables()
Dim db As Database
Dim ITables As Recordset
Set db = CurrentDb
Set ITables = db.OpenRecordset("Tables", dbOpenDynaset)
Do Until ITables.EOF
Call ImportData(ITables![TableName], _
ITables![SpecificationName], _
ITables![FileName], _
ITables![DeleteExisting], _
ITables![Use])
ITables.MoveNext
Loop
ITables.Close
End Function
There are several SAS statements that can start external programs, including
%sysexec
call system
filename pipe
Access has the command line switch /x mymacro that will run a specific macro at startup, or you can create or update the AutoExec macro that is also run automatically every time Access is started.
So your SAS code might look like
%Spit;
%sysexec msaccess /x ImportTablesMacro;
#Richard shows you how to call Access from SAS. If you do not have the ability to run command lines from your SAS session (some system administrators disable this), you can write a shell script.
First call SAS to create the .txt files.
Then call Access with the method Richard describes to run the macro.
I have an Access table where each item has attached a Visio file (.vsd).
In my Access form, I would like to see the file. I don't care if it is an editable Visio file, a preview or just an image.
I have built a VBA code that let me load the Visio file from a Directory. But I need to load the file from a table.
Here my VBA code.
Private Sub Carica_Dati()
Dim path As String
path = "C:\Users\VisioFlow_001.vsd"
With Me.VisioObject ' name of the OLE Object where I want to put the Visio file
.Class = "Visio.Drawing.11"
.OLETypeAllowed = acOLELinked
.SourceDoc = path ' HERE I WANT TO LOAD THE FILE FROM A TABLE OF THE DB
.Enabled = True
.Locked = False
.Action = acOLECreateLink
.SizeMode = acOLESizeZoom
End With
End Sub
Here a preview of the form.
UPDATE
Here a picture to show how the file is attached to the table.
Since attachment fields in Access aren't very consistent, directly loading them into an OLE object is not an option, unless you're willing to do sophisticated things
Microsofts documentation on attachments can be found here
My observations on attachments: the binary data field contains one of the following:
Some characters I can't identify + the file type + the file data appended to it
Some characters I can't identify + the file type + a compressed version of the file data appended to it
Microsoft, in all it's wisdom, has supplied us with a way to save the original file to the disk, but hasn't supplied us with a way to remove those initial characters and the file type from the actual file data, or an easy way to identify if the file is compressed or not (you can check the file type with the table supplied in the link to check if it should be).
In conclusion, you're probably off best either replacing your attachment field with an OLE object in the database, or writing the attachment files to disk before displaying them.
If you use an OLE object field, and load them in as long binary data (not through the GUI), you can easily achieve the behaviour you seek without writing the file to disk, since the binary data is available without any extra characters.
To write an attachment file to disk:
Dim rsForm As DAO.Recordset2
Dim rsFiles As DAO.Recordset2
Set rsForm = Me.Recordset
Set rsFiles = rsForm.Fields("attachment_column").Value
If Not rsFiles.EOF Then
Dim fileLocation As String
fileLocation = Environ("TEMP") & rsFiles.Fields("FileName").Value
rsFiles.Fields("FileData").SaveToFile fileLocation
'Your existing code to display the OLE object here
End If
You do not want to use the Attachment feature. Its purpose is different than what you are attempting.
Put the images into their own stand alone folder outside of the database.
In the table that holds the records for your main form - you need a new field which holds the path & image file name. This is a text field. (If the path segment is uniform for all one can insert that elsewhere via code rather than store it in this field.)
Then in form design - use the image control. This control (all controls) have a source property - that will change with each record using that field that holds the path & file name.
Do a bing/google on the topic of changing an image with every record - the set up isn't intuitive necessarily. Note that older editions did things differently so be sure you get relatively recent advice.
Then when you are using the form and change records - the image will change.
Note after having typed all this.... I have no idea if the visio file type works - I know that jpg and bmp do... so first sanity check a simple fixed image with that file type to see if it works ...
The following lines of code should export data from a query to a *.txt file, but results in an error.
strPath = "N:\apprais\targetDirectory\"
DoCmd.TransferText acExportDelim, "spcDataFile", "qryExportAppraisal", strPath & "DATAFILE.TXT"
Based on this https://msdn.microsoft.com/en-us/library/office/ff835958.aspx, I don't think it should be necessary to have a Schema.ini file (unless it's a fixed-width file). Also when I executed the command in an older version of the application, I was able to export the data from the query to the *.txt file without the Schema.ini file.
Ultimately, I need to know if I'm correct about the Schema.ini, and if I am, is there a default location that specification files are saved to in Access 2010? I can't seem to find where it's defined. I've looked in External Data > Saved Imports/Exports, but am not able to find anything resembling spcDataFile
I created a test MS Access DB to export a table to Excel and a text file.
This works for Excel:
DoCmd.OutputTo acOutputQuery, "QryExportToExcel", _
acFormatXLS, XFile, False
For the text file, I created a specification and used this code
DoCmd.TransferText acExportDelim, "Mytable Import Specification", "mytable", "D:\myfolder\test1.txt", False
In the error message, I get "test1#txt".
The Microsoft Office Access database engine could not find the object
"test1#txt". Make sure the object exists and that you spell its name
and the path name correctly.
I tried creating test1.txt in the same path. To my surprise, this deleted the file which is already present.
Software: MS ACCESS 2007
The Microsoft Office Access databasse engine could not find the object "test1#txt". Make sure the object exists and that you spell its name and path name correctly.
This is a generic (and rather useless) error message that Access outputs in case anything goes wrong. One example would be a misspelled field name in the import/export specification.
You can get the "real" error message by trying the import operation "manually" in the Access user interface (rather than through code).
The question author reported the problem was "because I was using an Import Specification for Exporting a file."
They resolved the problem by using an Export Specification.
Because you are doing DoCmd.TransferText, Access is expecting that the file Test1.txt exists in that location. Try creating the file first, and then do a transfer of the text.
You can try this code before the export to create the file:
Public Sub CreateExportFile()
Dim strFileName As String
Dim SomeStringToOutput
strFileName = "d:\myfolder\test1.txt"
Open strFileName For Output As #1
End Sub
I was having a similar situation and found that a file schema.ini was in the destination folder. This was created when an acExportMerge was performed previously and it caused this error. Make sure that file has been deleted prior to executing a new TransferText.