From: b.f.lundin@gmail.com   
      
   >    
   > > However the struct (which is autogenerated from the table definition)   
   >    
   > I think this is the error. Just as you should not always use SELECT *,    
   > you should use the same object all over town just because the data    
   > comes from the same table. Rather you should have a record type per stored   
   > procedure or somesuch.   
      
   We do not have any stored procedures.   
      
   And here is a clearly a difference in opinion.   
   I do not see 'select *' as an error or as a problem.   
   Going your route, means total redesign, which I am not interested in.   
   This is a totally different question than the original.   
   But I see you answered that one below.   
      
   As a side note   
   All sql is within the Ada code, sent to the db as SQLPrepare   
   Then the bind parameters are set with SQLBindParameter.   
   (Which I now see is a generic ifc to SQLBindParameter)   
   There's also a call to SQLDescribeParam, when binding.   
      
   I should mention that the Ada code is daemons/services with no GUI.   
      
       
   > My experience from having worked with a system that has lived for a   
   > long time, is that everyonce in a while I would find columns that    
   > were useful once, maybe with a previous customer, but which smells   
   > funny.    
      
   Those coulumns gets into the customers adaptions. And there they are used.   
   They do not enter into the standard product.   
      
   >Or that the need of a column (or an entire table) disappears.   
   That happens, but very rarely.   
   And when it does, the compiler lets us know where the trouble is at,   
   since it would complain on use of members in the struct that are not present.   
       
   > There is also the situation that a new requirement could possibly be   
   > bundled with some existing functionality.   
   Same thing there, The compiler tells us.   
   New field? No problem, it is filled with value seince we do 'select *'.   
   Just use it, after the table_package/struct is regenerated.   
      
      
   > All these are situations where I wanted to first find the references in   
   > the database code, and then sometimes look further in the client code   
   > to see if the idea I had could be pursued.   
   No 'database code' in this system. All sqls are in Ada code.   
      
   The client on the other hand, reads from views. It is read only, and send   
   messages   
   over a socket if it wants to update something. All DML are in services in Ada   
   code.   
   This way, we can change GUI, which we have done. (Gui gen 3 C#, looking at gen   
   4 now - html5)   
      
      
      
   > I found in the entry for SQLGetData for SQL Server Native Client that it    
   > says: "The SQL Server Native Client ODBC driver does not support using    
   > SQLGetData to retrieve data in random column order.".   
      
   Thanks, this is what I was after. But I really hoped to find   
   a parameter to send in, just as MARS=yes.   
      
      
   >    
   > > Are there any other driver that lets me retrieve values from a resultset    
   > > in the order I choose?   
   >    
   > There are a couple of vendors on the market, but I would guess   
   > they mainly focus on non-Windows platforms. They may also be less   
   > complete than Microsoft.   
      
   Ok. The only time we would use that would be when I port the system to ARM,    
   and a raspberry PI. There is no Oracle client for ARM. But there is unixodbc   
   for sql-server. But that is in the future.   
      
      
      
   >    
   >    
   > As I said, I am not very well versed in ODBC, but it appears that binding   
   > columns with SQLBindCol is an alternative, although it may not fit well   
   > with Ada. But given this restriction, this is an accident waiting to happen   
   > unless you bundle it properly. I am thinking that you would use something   
   > that uses SQLDescribeCol to find out the column order, and then    
   > retrieves the column to fill the record. But I only have a dim idea   
   > of how that would work.   
      
   Well, the 'select *' combined with the autogenerated struct works fine.   
   They take care of picking the cols in correct order.   
   It is the case for old sites, where 'select col_A, col_B, col_C' are   
   more common. The following get()s are handwritten, and _may_ have the   
   wrong order. But I guess there is no substitute for testing,testing...   
      
   >    
   > I will have to learn ODBC one day, since my interface for Perl programmers   
   > uses OLE DB, and Microsoft has deprecated OLE DB as a means of connection   
   > to SQL Server.   
      
   Raw ODBC is no fun. On the other hand, raw OCI is even worse.   
   Abstraction layers make stuff MUCH easier.   
      
      
   Having set the first live site with Sql-server, I am pleasantly surprised over   
   using it. The management tools are much better than Oracles.   
      
   Once I got past locking problems, by running in 'READ COMMITED SNAPSHOT' as   
   I think you once tipped me to, the only 'problem' remaining is the column   
   order in get()s.   
   The faking of sequences (as in getting a number from db OUTSIDE a transction)   
   by inserting a record in a dummy table, getting its rowid, and delete it,   
   works well.   
   It will be replaced by the native solution present in sql-server 2012.   
      
      
   I do have another question, but that will be a new thread   
      
   Thanks for the replies   
      
   --   
   Björn Lundin   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)