I'm not new to Access, but am very new to VBA coding. Our management software is horrible, but it's the best that is available in the industry and I have created many many reports using Access, but have new problem now.
Attachments in the system are stored in one central location and then the file name stored in a SQL table. I have created queries to pull the full file path including the file name. Would it be possible to use some VBA coding to print all the existing PDFs in sequence from the paths returned in the query?
Thank you for any and all help!
Native VBA controls the collections of methods and attributes from Office.
An existent PDF is not the case (Access can create one or open, but not open and print).
To open a file with full path you will need to perform a select from table and perform a loop to shell open file, after that, sendkeys ^P.
But I strongly recomend to use another tool to do it, like Auto Hotkey or AutoIt.
Related
I did search many times to find a proper solution, but till today I didn't find a proper solution for my function. Target is to open a schedule from the server using VBA either from within MS Project or MS Excel using only part of the mpp filename.
We do have a ProjectID for each schedule. Unfortunately, this is only part of the file name and the rest even changes from time to time:
Example: ProjectID_Department_Projectname
With FileOpenEx I can easily open a file from the server using full file name. I wonder now if there is a way to use part of the name.
-Is there a function to open a file using placeholders?
or alternatively
-Does anyone know how to loop through all files on project server or retrieve a list of files?
Good Afternoon,
I am in the process of developing in vb.net a simple “cheque printing” application which will allow users to fill in a few text boxes with the values that will be printed on a cheque.
When they hit the print button, the values will be sent to the printer, but I also want the values they input in the text boxes saved to a file, so like a history file of all the cheques that were created.
I am thinking to use either an access database or an excel spreadsheet as my history file, but I am not quite sure on which would be best.
Please note that in my environment storing this information in a SQL database is not an option and also this file will most likely be stored/accessed from the network.
The history file needs to be:
1.Stable (cannot corrupt easy)
2.Reliable
3.Easily exportable in case we need to export the information to one of our in-house systems.
4.editable from the application I am developing
Kindly advise,
A
XML. Save the data to DataTable object and then use the .WriteXML method to save it as an xml file. I'd advise creating a strongly-typed DataTable class for this, so that the XML can be exported with a reliable schema and imported easily.
If you are using different fonts, you could use a .rtf (rich text format) which will save the format of the text that you send to print... it is a universal file format, you can open it with open office, ms office, or any office suite you have...
Access will be best choice,
it's relational database and can make a form from this file to do what are you looking for without VB or any code.
Also you can access this file from network.
for more detail about setting for this file go to this link
http://goo.gl/bOfGp6
and you will find more options complete your work.
I would use a MySQL server. It's free.
XML is also good, but I hate sharing folders...
I am working with SharePoint 2010. I need to get the data from excel file stored in sharepoint library. I have plans to accomplish this by using OLEDB connection. So I need to download the excel file from doc library and store it in a temporary location and then access this temp file to get data from it. Now my question is which is the best ans safe location to stored the downloaded file? So far I have used SharePoint's layouts directory, C:windows:TEMP and even Path.GetTempFileName(). But the result I get this is " ACCESS DENIED!". Any ideas in temporary location? Is there any other location which is safe?
Thanks
Check whether you are running the file saving code with Run with elevated privileges and the app pool account has write access to the provided path. It's not a good practice to store temp files inside 14 hive.
Why don't you use Excel Web services to read the excel file if your farm has excel services enabled.
Refer http://msdn.microsoft.com/en-us/library/ms500767%28v=office.14%29.aspx
Or else try to use third party libraries like EPPlus where you can open the excel file using a stream rather than from a physical file location.
How to edit a Word Document (.docx) stored in a SQL Server Table?
Here is the tentative work flow:
Read BLOB from SQL Table through Ideablade
Write BLOB to disk as .docx
Open .docx using Word
User makes changes
Save .docx using Word
Read .docx into BLOB
Write BLOB back to SQL Table through Ideablade
All sample code is welcomed?
I am sure there are a lot of people doing this already.
Any other ideas on how to simplify this process?
I am using VB.NET, .NET 3.5 SP1, WinForm and SQL Server 2008.
Well, as to the how, here is how to read a blob and write a blob to SQL. Although frankly, unless you have very good reasons such as an existing backup system, you would probably be best served storing the file to the file system and the path and metadata in the database. Either way, abstract it in your BLL, so you can change your mind down the road.
Retrieving and updating the BLOB from the db shouldn't be a problem, you'll find lots of sample code to do that on the net.
A simple approach to your problem would be to create a "temp" or "working" directory somewhere and monitor it with System.IO.FileSystemWatcher (sample code). When the user wants to edit a file, fetch it from the db and store it the directory. Whenever the user saves the file, you'll get a notification from your FileSystemWatcher, so you can save it to the database. Don't forget to empty the directory from time to time.
The method I've seen for this that I think works best is to build this as an add-on for MS Word itself. Examples include the Save to Sharepoint, Save to Moodle, and other similar add-ins.
I want to create a program that could generate reports from an ms access database and place it on ms word, how can I do that. Please help, I dont have any idea on how to do this.
If you're doing this from vb.net, it seems to me that it would be simpler to automate Word, which has no difficulty utilizing Jet/ACE data as data source. I don't see any reason to involve the Access application in this, unless you have complex logic that needs to be executed within Access to get correct results in Word. For instance, Word doesn't do parent/child data display very well, but Access reports do that very easily.
Another question is the final disposition of the results. It may be that you don't need Word at all, e.g., if you're using Word for nothing more than generating PDFs. In that case, it might make more sense to create Access reports and output those to PDF (there's an add-in available for for A2007, and in previous versions, you can use the VB automatable PDFCreator, which is free).
In short, my conclusions would be:
if you're just merging data in Word from a Jet/ACE data store, then automate Word.
if you need to execute complex logic, it's probably better to automate Access and either output Access reports directly, or automate Word from Access.
In neither case, I believe, would you be automating both Word and Access directly from your VB.NET application.
You should connect to the Access Database using a Typed Dataset.
Right-click the project, click Add New Item, select Typed Dataset, and follow the wizard.
To control Word, add a reference to Microsoft.Office.Word and use the Application class.
You can build reports in MS Access that have the Export to Word functionality built into them.
You can invoke the report from your code and then call the export functionality and give it parameters so that it will export to a .doc file that you name. You can then invoke MS Word and open the .doc file up for display.