Results 1 to 15 of 15
  1. #1
    Join Date
    Dec 2005
    Posts
    8

    Unanswered: Autofit column in table view

    We are doing a data dump where we print screenshots of the tables to .tiff's and go from there. In the DB in particular, we have about 15 tables with 20-40 columns a piece. They all have to be resized and I was hoping there might be a default or setting option to set the colums to autoformat width. Does anyone know of such an option?

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    wha?

    Could you provide a bit more detail of the process you're undergoing? This sounds very unusual and there is a good possibility we could save you from a whole bunch of manual work...
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  3. #3
    Join Date
    Dec 2005
    Posts
    8
    I work for a scanning and electronic data recovery company. We aren't using this DB so much for any function. We simply want to see the data in the tables.

    The problem is, many of the tables are minimized in terms of width so you can't actually read what they have in them. The only way to make the data useable is to manually resize each column, which, with 800+ columns, can be painstakingly slow and inefficient. My hope is that there is a way to change a setting (even within a table would be great) to resize the table view column widths so it doesn't have to be hand adjusted.

  4. #4
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Not exactly, you can create a report that looks a whole lot like a table and restrict field widths that way. This still sounds funny to me. What are you doing with the data after you "view" it. Also, access has a hard limit of 255 columns in a table IIRC.

    you could try selecting all the columns and double clicking on a divider. Still, this one is boggling my noodle, there's more too it than you're telling us...
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    its the dumping of the data into TIFF's that concerns me, why TIFF's, why images?
    What is the fnction of he process, IE why is it being done, would a report to say PDF meet the user requirment?

  6. #6
    Join Date
    Dec 2005
    Posts
    8
    Quote Originally Posted by Teddy
    Not exactly, you can create a report that looks a whole lot like a table and restrict field widths that way. This still sounds funny to me. What are you doing with the data after you "view" it. Also, access has a hard limit of 255 columns in a table IIRC.

    you could try selecting all the columns and double clicking on a divider. Still, this one is boggling my noodle, there's more too it than you're telling us...
    No, it's really a lot simpler than you guys are probably thinking. All we do is electronic discovery. These are other people's databases. We open them up, run Zprint (a batch image processing program) that creates screenshots into TIFF's and spits out the tiff images for the DB in question. The client is interested in the information in the columns, so I have to try to find an efficient way to see the tables, not reports. Tabular data (and format) are what I'm after. The program to create the TIFF's works fine now. I just want to avoid resizing manually.

  7. #7
    Join Date
    Dec 2005
    Posts
    8
    Quote Originally Posted by healdem
    its the dumping of the data into TIFF's that concerns me, why TIFF's, why images?
    What is the fnction of he process, IE why is it being done, would a report to say PDF meet the user requirment?
    No, PDF won't work because we import from this stage (one of about five for this procedure) into other software and PDF's are much less efficient than TIFF's. Also, we're talking about 100,000+ 8.5" x 11" images. That's a lot of work for distiller.

  8. #8
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    We're asking you for an overview of the PROCEDURE, not so much the technology. WHY are you doing it this way, not how...
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  9. #9
    Join Date
    Dec 2005
    Posts
    8
    The databases are not ours, so we cannot do any reformatting other than in the tables themselves. Aside from resizing, we cannot modify anything. Without creating a dummy DB and run the risk of losing time-stamped data, we have to stick with this approach.

    I'm not sure what part of the procedure isn't clear. We get the DB, open it and run Zprint. Zprint scrolls through the tables, does screen shots and saves the screen shots to TIFF. The table is not modified in anyway whatsoever unless we do it before we run the Zprint app.

    Does that make sense?

  10. #10
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Why TIFF instead of using a copy of the database? What about hitting the database via ADO or DAO and iterating through the table collection to spit out a text file or suck it into another database? I guess I (and I assume healdem) am trying to get my head around why you would want to look at an image instead of just the data? It is fairly simple to pull all the tables into another database without losing any of the data...
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  11. #11
    Join Date
    Dec 2005
    Posts
    8
    We are not DB programmers per se. We use them, but our focus is data, not DB's. Once we get the images, we import them into other databases where the TIFF's simply act as documented reference to the information in the original DB. Were we to recreate the documents another way, it wouldn't be an accurate reflection of the data as is.

    I think the term data is unclear here. Data in the db is simply imformation to us. We use the images as data for our processes. Whatever information we are converting into our data is irrelevant. Here, we are simply trying to access the information in an intelligble, meaningful way. If it's unreadable in the TIFF, it's useless for us. The next step, by the way, is OCR on the TIFF's.

    I'll talk with our DB programmer about using a COM approach.

  12. #12
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    woah... From Access to TIFF then back to a useable format using OCR?

    Where does the data get stored after OCR? I am 99% certain you could automate this whole process without resorting to literal image snapshots. A halfway respectable SQL archival database would take care of it for you and provide simple, reliable means of acquiring and analyzing the information.

    On the other hand, if those TIFF's are used for other non-database items, it could become a bit more complicated. But still, it would make more sense to pull all of the data into a central repository and generate the TIFF's as needed instead of starting with data, taking a picture of it, then turning it back into data.

    There are other ways you could leverage SQL Server or Oracle to store any array of information in the same container as well, streaming to an OLE/BLOB field comes to mind...
    Last edited by Teddy; 12-15-05 at 14:53.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  13. #13
    Join Date
    Dec 2005
    Posts
    8
    Without dragging out DB programmer off of a major project, I don't think we would be able to do that quickly or efficiently. We are importing these images into another DB, but the secondary DB is weak at best. The secondary DB mainly is to create load files for clients after we format the data and develop a functioning DB from the data they send us.

    Yes, it's a LONG way around the block and there are undoubtedly faster, cleaner, easier methods. Our niche is to use the tools we have to get low-level data depth to images and organize (read structred DB) the images with client specific keys. Unfortunately, we aim for fast and determine hard cutoffs on productivity. Since we may use a workaround like this once or twice every 4 years the boss says, "Just do it by hand...the DB programmer is too important doing what he's doing to deal with something like this."

    This DB resize issue was really just a very small task in a 150k page print job. I just didn't feel like spending 5 hours clicking places on the screen. Without dragging our programmer in (and decreasing his productivity), I think manual will be the best option.

    Oh, one more note, the images are not maintained on our database. We simply bring them in, use them to create a functional DB structure, then send them to the client. In the end, the images are project specific, so we don't bother keeping a catalogued repository. Once the project is gone, so are the images.

  14. #14
    Join Date
    Dec 2005
    Posts
    1

    Autofit Access Fields

    I literally choked on my Diet Coke when I read the part about OCRing the TIFFs... I was afraid that's what this was leading up to.

    As for a simple way to autosize the fields in Access, there isn't one. "Best Fit" only works on visible records and none that are offscreen. The good news is, you don't need to do any of this stuff the way you're doing it.

    I know you want a quick way that makes use of the tools and knowledge you already have, but beleive me when I say this will be much less painful if you spend a few minutes or even hours to learn some simple ways to script Access to just save the tables out to a standard file format (such as DoCmd.TransferText to output text) that your other database app can import.

    Please seriously consider abandoning the TIFF/OCR method before someone chokes on something more dangerous than Diet Coke.

  15. #15
    Join Date
    Dec 2005
    Posts
    8
    Okay, diet coke aside...I realized I confused myself. We're not OCR'ing.

    The answer to the question...no, no resize in the table view.

    Trying to grapple with new company procedures is always fun isn't it!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •