Problems with dbfcmd string acceptance length 
Author Message
 Problems with dbfcmd string acceptance length

Hi folks...

I have written a front end application to SYBASE, and one thing it does is
provides a function to create new tables.  Everything seemed to work fine,
until it ran across a very large table with many, many columns.  The text
passed to the command buffer through dbfcmd is very large, approximately
2500 characters.  Now, SYBASE doesn't seem to like this, and I've read in the
DB-Library/C Reference manual that:

"The size of the space it [dbfcmd working buffer] allocates is equal to the
maximum of a defined constant (1024) and the string length of cmdstring * 2."

Now, my application has the possibility of passing very large strings, such
as the one described above, to this working buffer.  I was wondering it there
was anyway to get around this problem, without having to break up the
commands into multiple calls.  Besides, this can't be trivially accomplished
with the create table command, because adding columns in SYBASE requires them
to allow NULLS, which is not necessarily what I want.  NOT NULL columns can
only be specified in the original create table statement.

Any help/advice appreciated!

==============================================================================
== Chase Hacker                          "Fortune presents gifts not        ==


==============================================================================



Fri, 29 Dec 1995 23:54:58 GMT
 Problems with dbfcmd string acceptance length

I have also faced a similar problem but found it to be a misunder-
standing of the limitations of the command(at least in my case).
Suppose I call dbfcmd like this :
dbfcmd(dbproc,"%s %s %s %s",arg1,arg2,arg3,arg4);
Working buffer for dbfcmd allocates a maximum of 1024 bytes,since
the format string is only 11 bytes long.But arguments may be quite large so that the working buffer might overflow.In my case each argument was of 512 bytes requiring a total of 2048 bytes.The solution was to split the calls  like dbfcmd(dbproc,"%s",arg1) etc.

Note that the command buffer does not have any such restrictions of
size.So you do not have to split the command across sqlexec's.

Hope this helps.

K.V.Vijayan
a much longer



Sat, 30 Dec 1995 01:16:24 GMT
 Problems with dbfcmd string acceptance length
My understanding is that dbfcmd() uses the standard C library sprintf()
function to format the command string.  It is therefore subject to the
same quirks and limitations as sprintf().  The only solution is to break
up the command into multiple dbfcmd() calls.
--
--------------------------------------------------------------------

Strong/Corneliuson Capital Mgmt          
  I believe that every right implies a responsibility; every
  opportunity, an obligation; every possesion, a duty.
  -- John D. Rockefeller


Sat, 30 Dec 1995 22:19:02 GMT
 Problems with dbfcmd string acceptance length
Can't you use sprintf and dbcmd()?

e.g.

sprintf(buf, "%s %s %s %s", arg1, arg2, arg3, arg4);
dbcmd(dbproc, buf);

David

|> I have also faced a similar problem but found it to be a misunder-
|> standing of the limitations of the command(at least in my case).
|> Suppose I call dbfcmd like this :
|> dbfcmd(dbproc,"%s %s %s %s",arg1,arg2,arg3,arg4);
|> Working buffer for dbfcmd allocates a maximum of 1024 bytes,since
|> the format string is only 11 bytes long.But arguments may be quite large so that the working buffer might overflow.In my case each argument was of 512 bytes requiring a total of 2048 bytes.The solution was to split the calls  like dbfcmd(dbproc,"%s",arg1)|>  etc.
|>
|> Note that the command buffer does not have any such restrictions of
|> size.So you do not have to split the command across sqlexec's.
|>
|> Hope this helps.
|>
|> K.V.Vijayan
|> a much longer
|>

--

David Van Couvering, Sybase, 1650 65th Street Emeryville, CA  94608
- Opinions expressed here are mine and not necessarily those of Sybase -



Sun, 31 Dec 1995 02:24:14 GMT
 Problems with dbfcmd string acceptance length
No, that's not quite true.  The difference is that dbfcmd has to internally
allocate space for the sprintf() buffer.  It does not know how big the
buffer needs to be (it all depends on the types of the following
arguments).  This is how it determines how big of a buffer to allocate:

        bufferSize = MAX(2 * strlen(formatString), 1024)

Needless to say this has its problems -- you still have a chance of
overwriting the buffer if all your format args convert into large
character strings.  That's why in general I like to use sprintf() and
then dbcmd()...  When you use sprintf(), you can allocate your
buffer to be as big as you like (up to the limitations of your machine),
and you don't have to worry about overwriting it.  The control is all in
your hands.  

As a matter of fact, I am pretty sure CT-Library, the new Open Client API,
does not even have a function that similar to dbfcmd(), and that
using sprintf() is now the recommended way of handling formatted strings.  
But I haven't scanned the reference manual to be sure of that...  Perhaps
someone in Connectivity development can confirm or deny that for me...

Thanks,

David


|> My understanding is that dbfcmd() uses the standard C library sprintf()
|> function to format the command string.  It is therefore subject to the
|> same quirks and limitations as sprintf().  The only solution is to break
|> up the command into multiple dbfcmd() calls.
|> --
|> --------------------------------------------------------------------

|> Strong/Corneliuson Capital Mgmt          
|>   I believe that every right implies a responsibility; every
|>   opportunity, an obligation; every possesion, a duty.
|>   -- John D. Rockefeller



Mon, 01 Jan 1996 00:51:10 GMT
 
 [ 5 post ] 

 Relevant Pages 

1. ADOX: Extending a fixed length Jet string field length

2. Zero length string converted to single space string.

3. Problem with default length of strings.

4. EXECUTE statement string length problem.

5. MySQL JDBC UNION problem - String length?

6. problem passing zero-length string parameters

7. Problems with zero-length strings

8. SQL Server 2000 date format acceptance

9. Need informal Acceptance Test for Oracle 7.3.4

10. Corporate Acceptance of Creating Views ?

11. ## help db-lib & dbfcmd

12. DBPROCESS dying and dbfcmd/dbcmd question.


 
Powered by phpBB® Forum Software