Just for some background, I'm a mechanical engineer at a company and the older folks here created a database in Access 2003 which basically takes an AutoCAD Drawing or a Picture OLE and plops it in a nicely framed report with a bunch of other information. I've been making some modifications to that database, one of which is to store all OLEObjects as links to actual files in our shared network. Every new file that has been added to the database for the past week or so has been linked and the guys seem to have gotten the hang of it.
My problem at this point in time is to try and retrieve all the Objects that are embedded in the tables. I've tried Lebans OLE to Disk but that doesn't seem to work with AutoCAD Drawings (which are .dwg and .dxf files) nor does it work with "Picture".
I know this is a quite controversial topic seeing as how I'm not providing any code to start with, but I think this is too complicated for me to even begin doing and I'm in over my head. Extracting the OLEObjects by hand isn't feasible since there's over 8000 of these spread through several databases. Is there any way to automate the extraction via code?
Thanks in advance,
Rafael.
If you access the Object property of the Bound Object Frame control, for an AutoCAD Drawing this should return the AutoCAD Document Object. You can then invoke the SaveAs method of the Document object to save the file to a known location.
For example, something like:
With Me.MyBoundObjectFrame.Object
.SaveAs "Drive:\YourPath\YourDrawing.dwg"
End With
Where MyBoundObjectFrame is the name of your Bound Object Frame control.
This works successfully in my limited testing.
Related
I have created an application in C# using visual studio 2010. The application uses a database and a ton of data bound controls.
I need to save a copy of the running application with what changes the user has made to a file they can double click and get their saved state back in the application.
I know I need to use a SaveFileDialog but other than I have no idea.
If all the controls are bound to data through datasets you could perhaps serialize and deserialize the underlying datasets to/from XML files in order to create some kind of "offline data file storage" feature.
Before introducing such a feature into your application you should, however, consider all the potential database synchronization issues that are potentially created though preservation of such a saved state within your application clients.
If you really only want to preserve window layout properties (such as window size, grid column width, sorted column, splitter positions etc) you have to focus on those properties only.
Here is a thread with a similar discussion
Hey guys I've written a little module/macro that helps our inventory department, they will need to run the module/macro a few times every month. They receive the databases from out in the field these are exported from some 3rd party inventory tracking system we have.
My question, is there any way to install this module/macro outside of the db file but still within access so that the inventory management team does not have to open vb editor, import the module, create a new macro, name it, set it up properly to execute the function?
The module/macro does not need to be changed for any new database that comes in.
Basically they need to be able to open any database received by the field and have this functionality in the module/macro available to them without having to set this. Is this possible?
You could look at my article for vb123.com:
Using Database Library Files in Your Access Application
The thinking there is that you can put access objects in a library file (still an mdb or mde file, or any of the new access file types) and then by just adding a reference to the file in your VBE project, you get that functionality made available to you.
It works with forms, reports, queries, classes, etc. To be honest, I haven't tried it with macros, but don't see a reason why it wouldn't work.
The beauty is that reusable functionality is packaged into one file, that is still just a plain old access file.
If you had the inclination, you could also write an access add in that basically calls your macro in the library.
We did this with a product for making dealing with SQL much easier in Access, and it has worked for years with Access installations all over the world. You can install the add in using a professional installation package such as wise installation, making it a pretty seamless experience for the end user of your macro. However, there is a considerable overhead in writing this kind of setup in a professional way. Depends on what your users need, I suppose.
Perhaps you are thinking of VBScript or a back-end, front-end set up?
You can use VBScript to perform actions on an Access database, through the Access object, with ADO and so on. The script can either accept command line input, request information, or run against any database in the current directory.
With back-end front-end, the new database becomes the back-end and the Access file with your macro is the front-end. Your macro should ask the user for the name of the back-end file and either use that with the Access object or link the tables, according to what is needed to be done.
We have developed a consolidation function that will be used by other processes and want to position the function in its own MDB (call it "remote") so that it can be referenced and called from "caller.mdb" when its needed. The function is designed to return an array and works great when executed called directly from within "remote." However, with "remote" properly referenced in the "caller" VBA project, when "caller" makes the call the function returns errors. We get a variety of errors such as
3078: Jet cannot find the input table or query
QUESTION. Within "remote", how does one properly set references to the db and its local objects (e.g. one table and several queries including INSERT and UPDATE queries)? CurrentDB is apparently not the answer; we have also experimented with the AccessObject and CodeData objects. "Remote" and "caller" currently reside on the same drive, so that wouldn't seem to be the problem.
Instead of CurrentDb you could use with CodeDb wich points to the mdb currently executing the code.
Set db = CodeDb
The way Access itself does this (with all the wizards, which are all programmed in Access), is to use Application.Run. It does mean the code you're calling has to be a function, though it doesn't matter what it returns. Application.Run requires no references, just a path:
Application.Run("MyCodeDatabase.MyFunction()")
Obviously, if the code database is not in the path that Access uses (which includes its own app folders (including the app-specific folders in the user's profile) and the folder where your main application front end is stored), you'll need to specify the full path.
Application.Run() is a function that returns a value, but it is typed as variant. This may or may not work with your array. It's not clear from the object browser whether or not the arguments are passed ByVal or ByRef, but if they are ByRef (which is what I'd expect), you might just pass the array in and let the function work on it and then use it after the code in the remote database has completed.
On the other hand, the arguments are probably variants, so there's not much difference between that approach and just using the structure returned by Application.Run().
Marcand gave you the answer to your immediate question. There are other problems and irritations when it comes to using add-ins or referenced Access databases. See my Add-in Tips, Hints and Gotchas page.
There are a number of differences and nuances to calling forms and functions through a reference in a another MDB or ADP. I have run into issues in both situations, and what you are referring to as the "remote" database, I refer to as a central library.
At my Tips and Tricks page at http://www.mooresw.com/tips.php, I have pages devoted to programatically changing references, getting Access to search for the referenced file instead of having a broken reference, and calling forms through a reference.
Programatically changing references is needed when you publish the database from the development environment to the user or production environment. When working in the development folder, it's fine for the program to have a reference to the central library directly, but we wouldn't want code that 20 users are running tying up the central library in our development area. (An MDB file opened through a reference gets locked just as though your users were opening it directly)
The situation of running a form in a central library (or "remote" database) where there are no links or tables can be tricky. In that situation I've chosen to open a connection to the "caller.mdb" using ADO code with a Jet connection string in the open event of the forms. Doing so provides the ability for the code in the form (or functions in the library) to gain access to the tables and queries in the calling mdb.
For further information, see my pages at the tips link above, and in particular, see:
http://www.mooresw.com/call_a_form_in_another_MDB_through_a_reference.php
which I believe is most relevant to your situation.
Background: We have an old (but business-critical) SQL Server database with an MS Access ADP front-end; this was originally upsized to SQL Server from a series of Access databases.
This database tracks hazardous materials for our customers, and stores a large number of images. These images are inserted from MS Access, and get put into the database as OLE Objects.
The problems are:
These are a pain to read out in anything except Access/Office
There's a MASSIVE storage overhead - ~10GB of images takes up 600+ GB of storage space(!)
My question is this: what way would you recommend to convert these bloated objects back into simple JPEGs? Once we do this we can finally migrate our front-end from Access and onto a simple web-based system, and our backup times will become manageable again!
Take the *.bas file from here http:http://stackoverflow.com/Content/img/wmd/ul.png//www.access-im-unternehmen.de/index1.php?BeitragID=337&id=300 (unfortunately it is German).
It uses the GDI+ lib from MS (included in Win standard installation) to import/export pics to/from Access OLE.
Rough translation of interface:
IsGDIPInstalled: Checks for installation of GDI+
InitGDIP: Init of GDI+.
ShutDownGDIP: Deinit of GDI+ (importand to be used!)
LoadPictureGDIP: Loads pic in StdPicture object (bmp, gif, jp(e)g, tif, png, wmf, emf and ico).
ResampleGDIP: Scales pic to new dimensions and sharpens if needed.
MakeThumbGDIP: Makes thumbnail and fills border with color.
GetDimensionsGDIP: Get dimensions in TSize-Struktur in pixel.
SavePicGDIPlus: Saves Picture objekt in file as BMP, GIF, PNG or JPG (jpg with given quality)
ArrayFromPicture: Returns a byte array of picutre to put pic into OLE field of table
ArrayToPicture: Creates byte array of OLE field of table containing a picture
Here is the link again: http://www.access-im-unternehmen.de/index1.php?BeitragID=337&id=300
Use Access MVP Stephen Lebans ExtractInventoryOLE tool to extract the OLE objects from a table to separate files.
http://www.lebans.com/oletodisk.htm
According to Lebans: "Does NOT require the original application that served as the OLE server to insert the object. Supports all MS Office documents, PDF, All images inserted by MS Photo Editor, MS Paint, and Paint Shop Pro. Also supports extraction of PACKAGE class including original Filename."
Also, Access 2007 stores OLE objects much more efficiently than the historical BMP formats of previous versions, so you would have a smaller storage space and be able to keep your Access app if you converted it from the 600+GB storage of SQL Server to Access 2007 accdb format. Your backup times would be manageable and you wouldn't need to spend time converting an Access front end to a web front end.
I think the reason your database becomes so bloated, is that the JPGs are also stored as bitmaps inside the "OLE object" structure, or so I've seen, depending on the method the JPEG was inserted.
This is not optimal, but: for every image in the database, I would programmatically create a dummy .doc containing just the image, then pass it through OpenOffice conversion, and extract the JPEG from the images subfolder of the produced OpenOffice document (which is a ZIP file).
I would then replace the OLE documents in the database with the raw JPEG data, but then I have no way for you to plainly display them in a custom application (unless it's a web app).
I have a .NET webforms front end that allows admin users to upload two .xls files for offline processing. As these files will be used for validation (and aggregation) I store these in an image field in a table.
My ultimate goal is to create an SSIS package that will process these files offline. Does anyone know how to use SSIS to read a blob from a table into its native (in this case .xls) format for use in a Data Flow task?
In my (admittedly limited) experience with SSIS, it is quite good at rapidly getting something up and running, but frusteratingly limited in getting something that "feels" like the most elegant, efficient solution to a programmer.
Since the Excel Source Editor seems to take only files as input, you need to give it a file or reimplement its functionality in code that can take a blob. I understand that this is unsatisfying, but in the end, this is a time saving tool.