Dbtool Does Nothing. Still Have Odbc Data Width Errors

RealHeavyDude

Well-Known Member
Not everything designed by "big" Progress partners is best practice. Having "everything" run with root privileges is just one example of it.

I wish you good luck with the security audit. Nevertheless, I suggest that you involve an experienced Progress/QAD consultant in order to work out what could be change without breaking QAD.
 
Yes. That is what I am doing (copy a db to MS SQL), while also learning a bit at a time about the DBMS properties of Progress since my company has had that (with QAD) for some years and will continue to have that QAD app for some years.
 
The comment in this thread about making a field mandatory yet having to rely on the application to "make it so" has me concerned. So I'd like to check if there are examples in my QAD database where a table's column is listed as N in sysprogress.syscolumns.is_nullable, but in the actual data this is violated. For this issue I don't want to rely on a copy of the data in SQL Server, so I want to run Progress code on it, MUCH preferably SQL code. Using the db copy I have in SQL Server, I can write a simple script to generate SQL statements for every possible column of the sort:
If Exists(Select * From SomeTable Where SomeColumn1 Is Null) Print 'SomeTable.SomeColumn1'
If Exists(Select * From SomeTable Where SomeColumn2 Is Null) Print 'SomeTable.SomeColumn2'
etc
But I don't see that syntax If Exists() Print 'stuff' and in my quick scan of the docs I don't see something similar. I looked at ESQL but that looks like a lot more statements (5 time the code of the IF Exists() Print example above? )
So I guess there is some really short 4GL that will do this. And I guess that will be my intro to start learning Progress 4GL. Can someone give me a few pointers to doing this simple query in 4GL code? Thanks.

maybe this will work
If Can-Find(tablename.columnname Where tablename.columnname=?) Then Display"tablename.columnname".

I'll give it a try. Hmmm, it wants a database name somewhere. I thought launching mpro with the database name and then just running one line of code like the above would work. Seems I need to do more.
 
Last edited:

TomBascom

Curmudgeon
The "make it so" part just means that if the application makes the field mandatory then the application will need to deal with any fallout from users (or programmers) who attempt to write records with such a field being NULL. (The attempt to do so will fail.) The right way to deal with this is to make sure that such things never go into an indexed field -- a big part of making that happen is to never use user-mutable data for index values... I somehow doubt that principle was followed when qad was written ;)

If you are going to have mandatory fields you can go crazy and put all sorts of application level data validity checking in place and try to ensure that there is never an unknown value in a mandatory field. Or you could trap error conditions and act appropriately when someone sneaks one past. You're going to need that error handling no matter how good your up front checks are so I suggest that you focus there and then try to prevent the most application data handling cases.

The more subtle point is that if the application was written to not care about mandatory fields then setting the attribute after the fact /could/ lead to problems when code that wasn't expecting to have to deal with those sorts of errors all of a sudden starts blowing up. It may seem like a great idea to dive into you schema and make every indexed field mandatory -- but you will almost certainly regret it unless you are starting with a clean sheet of paper.
 
if the application makes the field mandatory then the application will need to deal with any fallout from users (or programmers) who attempt to write records with such a field being NULL. (The attempt to do so will fail.)

I was talking about a database having fields marked as mandatory, so I don't know what "if the application makes the field mandatory" has to do with this.
 

TomBascom

Curmudgeon
Sloppy construction on my part. I should have said "database" in that spot. In my defense the lines between database and application are sometimes very fuzzy in the Progress world.
 
the lines between database and application are sometimes very fuzzy in the Progress world.

FWIW, I have a lot of experience using software where the database and application comes from the same vendor, including products where there was very little relational about the DBMS. Seems to me that every database vendor either tries to champion the fact that they are relational, or that they are not relational. Kind of like how some talk about socialism vs. capitalism, no DBMS is really 100% purely relational or 100% purely not relational. ...Well other than the article (I wish I saved a copy of that article) that once called Edlin a database. ;-) I think everyone could agree that the DOS edlin program is 100% not a RDBMS. ;-)
 
Top