× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: SQL vs DDS
  • From: John P Carr <jpcarr@xxxxxxxxxxxx>
  • Date: Wed, 25 Aug 1999 12:22:36 -0400


>Rob Berendt
>This sounds pretty good, and we've got our own development machine.  And we

>use SQL.  I was trying to think of reasons why to keep using DDS.
>
>On a production machine how would you recreate a file on the fly?  Granted,

>I try to get away from this as much as possible, but I used to write
applications 
>that contained CRTPF commands that used DDS.  I thought about the RUNSQLSTM

>command.  Thought this would be a neat area to keep my SQL source for my 
>files.  However RUNSQLSTM doesn't work on the production machines.  Perhaps

> I could put the source into a Query Management Query.  While the prompter 
>(STRQM) is only available on the development machine, it can be run, 
>(STRQMQRY, CRTQMQRY, etc) on any machine.  In fact we use STRQMQRY in the 
>RUNSQL command to give us a poor man's SQL on the production machines.
>
>But I do like the ability to combine a view and an index in DDS.

>And I still think it would be an improvement if STRSQL could prompt for
fields 
>from the database catalog.
>

I would go with your first thought and rethink why you would need to create
a 
new file on the fly regardless how you make it.    Maybe have one file that
you
delete the records on the fly,  (BTW,  I don't know why anyone would not be 
using ReUseDeleted Records *YES).    and reuse the same space. 
 Instead of Creating, Deleting,  Creating, Deleting.....

The machine will remember who you are and punish you for making it ;
Add to the catalog, Remove from the catalog, Add to the catalog,   
Remove from the catalog....

In addition to using a new tool,   we should also rethink our process. 
The use of most of the new funcitions in SQL (Constraints, etc)  will
require us to rethink HOW we Design our applications.    In the case
of Constraints for example,  Your programs better be ready for 
error messages on Updates/Writes/Deletes.   Also you have to 
remove all those edit checks in your applications and move them
to the Data Base.  (Right Bruce?)

John Carr
Try our PowerTech inhouse SQL classes.   www.400school.com






+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.