SQL / ODBC wish list

questions
,
1

Once again, the community is being asked for a wish list of SQL functionality.

Rather than posting the list on the NGs (where it is all but impossible to find later) or in Skype (ditto), I am posting it here in hopes that it doesnt get lost.

My recollection of the list:

  • Support native SQL data types without weird workarounds (bigint, datetime, timestamp, date, time, etc).
  • Move up to a more recent ODBC standard (someone else will need to fill in the blanks)
  • Offer opportunity to connect without forcing use of cursors.
  • Support OUTPUT parameter on SELECT (etc).
5 Likes
2

Offered by Dennis Evans:

table valued parameters (I think it is called associative arrays in Oracle but I would need to look that up to be sure) async stored procedure calls, improvements in SQLFetch, multiple result sets. no cursor by default, which is the ODBC default

3

More from DE: goes along with the merge statement used from prop:sql or any other valid sql command

4

Perhaps some improvements in buffer/large result set management. Buffer() is often guesswork.

1 Like
5

More from DE: bulk operations using the native client or ODBC 11/13 drivers,

6

These 4 improvements would indeed be a nice start.
I think we all recognize that SV has limited resources so staying focused on the most widespread needs is important.

7

Another one from Dennis, which a few people +1’d: while we are in sql fantasy land they should also fix the connection process. get rid of the open(table) nonsense and expose and open connection close connection function calls so you can use disconnected data sets. the idea of a single connection died a long time ago

3 Likes
8

What about a sane way to deal with something like VARCHAR(MAX) ?

2 Likes
9

I would +1000 this.

Plus if it is a connected situation, gracefully handling disconnect and reconnect would be nice

they should also fix the connection process. get rid of the open(table) nonsense and expose and open connection close connection function calls so you can use disconnected data sets. the idea of a single connection died a long time ago

3 Likes
10

Not having the application crash on SQL disconnect would be absolutely huge for our mission critical application.

1 Like