Results 1 to 8 of 8
  1. #1
    Join Date
    Feb 2007
    Location
    The Farm
    Posts
    35

    Unanswered: size of variable(s) tied to size of DB structure

    Is there a way to delcare a variable so that the size it tied to a field in an Access DB?

    Instead of
    Custname as String * 30

    something like

    Customername as [database].[file].[column]

    Thinking a little more advanced is it possible to say

    Type CustomerRecord as [database].[file]

    i.e. CustomerRecord is a type that contains all the columns in [file].

    Sorry if my terminology is off. Not much experience with VB.

    Thanks
    Bartron

    Liv'n down on the cube farm. Left, then another left, then right.

  2. #2
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    Not directly.

    I suppose you could declare dynamic arrays of 1 character strings, but, it would be quite inefficient. This would let you define the array size after opening the recordset ....

    However, why not just declare the variables as strings, and cast them as needed, using VB's conversion functions?

    One other point - in using ADO, It handles building a recordset which contains all the appropriate field types. The recordset is a collection of records, which is a collection of fields. The recordset also has some very nice methods available to use in filtering the records or persisting them.

    In some cases, (filtering/searching/sorting, for instance,) it is much more efficient to use the recordset's methods than it is to use an array of user defined types.
    Last edited by loquin; 11-05-07 at 17:10.
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


  3. #3
    Join Date
    Feb 2007
    Location
    The Farm
    Posts
    35
    Zooom. Splat!!! (the sound of an idea not having enough lift to go over my head, but not enough knowledge on my part to understand everything)

    I probably should also state that in am in VB6.

    Thanks for the input. I need to research what you have told me. I will probably be back with more questions. ... soon.
    Bartron

    Liv'n down on the cube farm. Left, then another left, then right.

  4. #4
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    Since you are new to VB w databases, I HIGHLY recommend that you review this ADO Tutorial at our VB sister-site.
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


  5. #5
    Join Date
    Feb 2007
    Location
    The Farm
    Posts
    35
    WOW!! Information in abundance. Looks like I have some surfing, at VB Extreme, and some reading to do.

    I hope you can jump start me on another issue, i.e. point me in the right direction. This app I am looking at appears to be handling printing, formatting, line counting, etc. internally. That is it is sending each line separately to the printer object. Problems that arise are inter-mixing of print job content and no ability to "Print Preview". I assume there is a more "modern" way to handle this. I plan on looking at the "Office Intergration" threads to create discreet print jobs but I am not sure what to do for "Print Preview". Maybe that will come along with file base printing. When I searched doc the only "print preview" that came up was for VCC+. Here are my questions in order of importance: Is there an easy way to do print preview without "Office Integration" and is "Office Integration" the route to take?

    Thanks for all your help. I really appreciate it. I have 20 years of programming experience but as you can tell it is not in VB. :-)
    Bartron

    Liv'n down on the cube farm. Left, then another left, then right.

  6. #6
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    Ok. One method for implementing print preview in VB is to print to the picture box object instead of the printer.

    A way to make this fairly transparent is, instead of using Printer.Print "Your String and Data Goes Here", add a printsub to do the job, and pass it the object to use, as well as what to print.

    This approach could be summarized as:

    Code:
    Sub PrintSub (ByRef Obj as Object, ByRef PrintData as Variant)
      Obj.Print PrintData
    End Sub
    More information on this approach can be found here.

    Now, if you'll be printing images also, you'll also want to make a similar PrintPicSub.


    A different approach is to load a form with a white background, and print to this form. After printing is complete, you can view the form. If you like what you see, print each object on the form to the printer, in the same location and size. (I would recommend using a pop-up menu for the print control)

    As a reference to this approach, take a look at Printform, or Print Form
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


  7. #7
    Join Date
    Feb 2007
    Location
    The Farm
    Posts
    35
    Loquin,

    You are the bomb! (not really my normal speech :-) )

    That is perfect place to start. The second approach seems to be much easier and straightforward. It also looks like a method you developed. Did you put it second out of modesty?

    Great stuff. Thanks.

    I realized after send my last post that I mis-spoke. It is not that I have no VB experience. It is just that it is not current and not my normal area of play.
    Bartron

    Liv'n down on the cube farm. Left, then another left, then right.

  8. #8
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    The first approach is the standard approach. It uses a picturebox, which requires substancially less memory per page instance than does a form.

    I started using a form as a base container many moons ago, when I was recreating the look and feel of a pre-printed, multi-part form for our purchase orders. During development, I placed all the images, lines and fixed text on the form, so that it mimicked the pre-printed form. Then, I placed a label on the form at each location that needed data from the database, each with the data field name in its .tag property. (For repeating data, such as the individual items of the PO, I placed one instance at the Line1 print position on the form, with each element as the first item of a control array. When populating the form's item data, load a new control array element for each line, move it into position, and fill it with data. Repeat until you've filled the page print area. Print the form, unload the line arrays, increment the page number, and continue...

    At runtime, you can then populate the labels with the appropriate data, and print the form by copying each object on the form to the printer.

    Since it uses objects as placeholders, you can change the printed appearance of your output just by editing the form in design view.
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


Posting Permissions

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