[SOLVED]Phantom code in fields

Scriptcase 7 Bugs
#1

This is weird behaviour;

I have a field idtbl_customer of type integer. It is the basis of a SELECT.

I changed the database schema for the SELECT LOOKUP SQL statement. At this point expected errors occured. I corrected the erroneous code, but the error persisted.

In desperation & exasperation I reverted the field in General Setting > Data Type to INTEGER to see if at least the without the SELECT LOOKUP I’d get a clean compile.

The error persisted:

SQL ERROR’s:
Field:idtbl_customers SELECT CONCAT( tbl_customers.customername,’ ‘, tbl_customers.company,’ ‘, tbl_postcodes.town,’ ', tbl_postcodes.postcode) AS detail FROM tbl_customers LEFT OUTER JOIN tbl_postcodes ON tbl_customers.idtbl_postcodes = tbl_postcodes.idtbl_postcodes ORDER BY tbl_customers.customername
(Unknown column ‘tbl_customers.customername’ in ‘field list’)

Field:idtbl_customers SELECT CONCAT( tbl_customers.customername,’ ‘, tbl_customers.company,’ ‘, tbl_postcodes.town,’ ', tbl_postcodes.postcode) AS detail FROM tbl_customers LEFT OUTER JOIN tbl_postcodes ON tbl_customers.idtbl_postcodes = tbl_postcodes.idtbl_postcodes ORDER BY tbl_customers.customername
(Unknown column ‘tbl_customers.customername’ in ‘field list’)

Field:idtbl_customers is NOT a SELECT field, yet fatal errors involving the original SELECT SQL persist. Note also that the error is listed twice.

The only work-around (kludge) I have found is to delete the whole form and start again.

#2

Sometimes when you change the type of a field the original data persists but is hidden due to disappearing blocks or fields. Imho it’s a bug, but would be nice if you could make a reproducable issue of this. SC is currently busy fixing a lot of issues, but they need clear samples of things that go wrong.

#3

Hi Albert,

I am able to reproduce this;

  1. create a SELECT field on a form, drawing the list from a database table
  2. compile
  3. change the database schema, so the detail part of the SELECT list becomes invalid.
  4. Compile; should generate an error about “field not found”
    *** Note that once or twice I find SC “locks” up at this point. I haven’t explored that problem since it’s easier for me to just restart apache2 on my Proliant Micro-server
  5. Correct the code.

At this point I get compiler errors as described, which are listed twice.

I have been experiencing SC lockups on other occasions as well, particularly when generating zip deployment files. The logs aren’t telling me much so I’m thinking about cleaning house and re-installing SC.

#4

Yes … the sql code in the lookup should only compiled, when the data type has a valid lookup setting.

#5

Hello,

Issue reported to our bugs team.

regards,
Bernhard Bernsmann

#6

Hello,

I performed some tests locally to simulate your problem. Could you tell me more details?
What is the datebase you are using?
I created applications with MySQL, PostgreSQL and SQL Server. Initially there was the problem, but I managed to make it work.

  • Change the SQL code of your field with the new schema and save the application.
  • Close and reopen the application, select the table with the new schema in SQL settings.

The problem I found was that when you change the schema of the database, the tables in Scriptcase remain with the previous schema,
so I had to close and open the application again to the new schema to appear.

I’ll request the developers to implement an icon of “updating” the tables in SQL settings in applications.

If this does not help you, let me know more about this problem.

#7

[QUOTE=John L. Santos;20166]
The problem I found was that when you change the schema of the database, […][/QUOTE]

That’s not the problem …

You have a form field, data type “Select” and for that a automatic lookup with sql code. Now you change your table schema, e.g. rename a field that inside the lookup. You compile and a error occurs … ok, you see that and can correct this.

Now, you change the data type from “Select” to “Text” or whatever and compile … No error at compile, but when the app is running appears an error that does not indicate that the lookup field is still filled with wrong code. Solution: the content of lookups may only be compiled if the data type is appropriate (“Select” etc.).

#8

Hello,

I sent an email to you for remote access.

#9

[SOLVED] Phantom code in fields

OK, I’m on top of it. ANd John, thanks for the email. This response in reply:

The development files are on my local server.

The Database was on a remote server, when the problem occurred. I should add that I noticed some other occasional weird behaviour with changes in application forms not being reflected when deployed to the remote server.

Somewhere about here it dawned on me to clear the browser’s (FF) cache. Bingo! The phantom code disappeared. Altered & deployed forms also reflected their changes.

Again, I need to concede there is also a problem between the back of my chair and my keyboard :frowning:

On that note, Seasonal Greetings to all.