Announcement

Collapse
No announcement yet.

SQLTools and bigint's

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SQLTools and bigint's

    I just bought SQLTools today to aid in my conversion of some code to PowerBASIC that uses a MySQL database.
    Let me first say that SQLTools is great, it's so easy to use and the fact that I don't have to keep track
    of handles makes it all the better.

    Now for my question.
    I have a table that has a column the contains signed bigint data. My problem is when I try to retireve the
    data via using SQL_ResColBInt(1) I get this ascii character:
    

    If I try to retrieve this column data using SQL_ResColText(1) I get this result:
    "[ CHR$(1) ][ CHR$(0) ][ CHR$(..."

    To make sure it wasn't something else in my program I simply changed the SQL-sel.bas example that came with
    SQLTools and I get the same result. Yes i know using bigint is excessive, but in the database I cannot guarantee
    that the data will fit into an Integer data type. I can retrieve all other data types just fine, it's only
    big integers I am having trouble with.

    Thanks for the help.

    Kevin


    ------------------
    Zimbi Inc.

  • #2
    Found out it's a limit in the MySQL ODBC driver and the workaround is to set the
    option "Change biging to int".

    Not sure how this will effect the system one the column count passes what an int
    is capable of holding. Guess I will run some tests and find out.

    Kevin

    ------------------
    Zimbi Inc.

    [This message has been edited by Voell, Kevin R (edited June 10, 2006).]

    Comment


    • #3
      > when the column count passes what an int is capable of holding.

      You have a table with more than 65536 columns?

      I might toy with splitting that table up into a couple of separate tables....

      (What does that have to do with 'bigint' data ... you wouldn't store the number of columns as a data column anyway, would you? We must be having some semantic difficulties here...)

      (And if you really need to store 64 bit integers, you could always store two 32-bit integers as discrete columns and put 'em together/take 'em apart as required).


      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        My bad, that should be row count not column count.
        The tables are slim only a few columns apiece, most tables contain a foreign key
        that points to the id in another table. some tables could be gigantic and have more then
        4 billion rows and an unsigned int will only handle 4.2 billion rows. I am looking at ways
        to split the tables up so they don't contain that many rows, it just seems excessive.

        Kevin
        ------------------
        Zimbi Inc.



        [This message has been edited by Voell, Kevin R (edited June 10, 2006).]

        Comment


        • #5
          > only handle 4.2 billion rows

          "Only" 4,200,000,000 rows? 2 rows for every three men women and children on Planet Earth?

          Well, if the DBMS supports it (which I would check very, very carefully), getting the return of a COUNT back is not a problem at all... instead of requesting the result be stored in a "bigint" you have it returned as a decimal character string and use VAL to convert it to a PB "QUAD Integer."



          [This message has been edited by Michael Mattias (edited June 10, 2006).]
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment

          Working...
          X