Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Design question (working with ATL OLE DB classes)....

Design question (working with ATL OLE DB classes)....

Scheduled Pinned Locked Moved C / C++ / MFC
c++databasequestioncomdesign
8 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    CherezZaboro
    wrote on last edited by
    #1

    So I have a lot of different C++ objects with members. Strings, ints etc. Objects get populated from database. Used to do it using MFC ODBC classes. Then I decided to go OLE DB. Wow! So. Now instead of CRecordset we use CAccessor<>, right? To map members to fields now I have to use TCHAR or CComBSTR for strings, right? But I'd like to keep my objects as CString or std::string. I don't want to change all my code to operate with CComBSTR and I don't want make parallel just members to transfer data from database to my members. What do I do then? Is there a way to make COLUMN_ENTRY to accept CString or std::string? Or somehow make an automatic transfer from one global CComBSTR (that would be used to retrieve the data) to those members? Confusing? :)

    D P 2 Replies Last reply
    0
    • C CherezZaboro

      So I have a lot of different C++ objects with members. Strings, ints etc. Objects get populated from database. Used to do it using MFC ODBC classes. Then I decided to go OLE DB. Wow! So. Now instead of CRecordset we use CAccessor<>, right? To map members to fields now I have to use TCHAR or CComBSTR for strings, right? But I'd like to keep my objects as CString or std::string. I don't want to change all my code to operate with CComBSTR and I don't want make parallel just members to transfer data from database to my members. What do I do then? Is there a way to make COLUMN_ENTRY to accept CString or std::string? Or somehow make an automatic transfer from one global CComBSTR (that would be used to retrieve the data) to those members? Confusing? :)

      D Offline
      D Offline
      Doug Mitchell
      wrote on last edited by
      #2

      ATL has a version of CString in atlstr.h. You should be able to use this.

      C 1 Reply Last reply
      0
      • D Doug Mitchell

        ATL has a version of CString in atlstr.h. You should be able to use this.

        C Offline
        C Offline
        CherezZaboro
        wrote on last edited by
        #3

        No,no,no. I need in VC 6.

        R 1 Reply Last reply
        0
        • C CherezZaboro

          No,no,no. I need in VC 6.

          R Offline
          R Offline
          Ryan Binns
          wrote on last edited by
          #4

          VC6 comes with ATL...

          Ryan

          "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

          C 1 Reply Last reply
          0
          • C CherezZaboro

            So I have a lot of different C++ objects with members. Strings, ints etc. Objects get populated from database. Used to do it using MFC ODBC classes. Then I decided to go OLE DB. Wow! So. Now instead of CRecordset we use CAccessor<>, right? To map members to fields now I have to use TCHAR or CComBSTR for strings, right? But I'd like to keep my objects as CString or std::string. I don't want to change all my code to operate with CComBSTR and I don't want make parallel just members to transfer data from database to my members. What do I do then? Is there a way to make COLUMN_ENTRY to accept CString or std::string? Or somehow make an automatic transfer from one global CComBSTR (that would be used to retrieve the data) to those members? Confusing? :)

            P Offline
            P Offline
            palbano
            wrote on last edited by
            #5

            Take a look at _bstr_t and _variant_t http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang__bstr_t.asp[^]

            -- signature under construction --

            -pete

            C 1 Reply Last reply
            0
            • R Ryan Binns

              VC6 comes with ATL...

              Ryan

              "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

              C Offline
              C Offline
              CherezZaboro
              wrote on last edited by
              #6

              But ATL in VC6 doesn't come with atlstr.h. It's in VC7. :((

              1 Reply Last reply
              0
              • P palbano

                Take a look at _bstr_t and _variant_t http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang__bstr_t.asp[^]

                -- signature under construction --

                -pete

                C Offline
                C Offline
                CherezZaboro
                wrote on last edited by
                #7

                Yeah. But how does it help? I can get data using CComBSTR just as well. But these macros: BEGIN_COLUMN_MAP(CUserRowset) COLUMN_ENTRY(1, m_bstrID) COLUMN_ENTRY(2, m_bstrDescription) .... END_COLUMN_MAP() for linking fields to members require members to be CComBSTR (or _bstr_t you are talking about). But my members are CString and/or std:string and I don't want to convert the rest of my code to use BSTRs.

                P 1 Reply Last reply
                0
                • C CherezZaboro

                  Yeah. But how does it help? I can get data using CComBSTR just as well. But these macros: BEGIN_COLUMN_MAP(CUserRowset) COLUMN_ENTRY(1, m_bstrID) COLUMN_ENTRY(2, m_bstrDescription) .... END_COLUMN_MAP() for linking fields to members require members to be CComBSTR (or _bstr_t you are talking about). But my members are CString and/or std:string and I don't want to convert the rest of my code to use BSTRs.

                  P Offline
                  P Offline
                  palbano
                  wrote on last edited by
                  #8

                  inner wrote: I don't want to convert the rest of my code to use BSTRs. You must whenever using COM interfaces. It is the COM form of string. Unless you want to use byte arrays which are not easier. At least _bstr_t has simple conversion interface to char and wchar making life easy to use CString and std::string/wstring :cool:

                  -- signature under construction --

                  -pete

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • World
                  • Users
                  • Groups