I have a table which have lots of fields.
When creating the form application i want to select only some fields from this table.
Where do i specify the fields to be used?
At the moment i can only see options for Hiding the fields and not removing them.
Please advise.
Thanks
Anil
You can always modify the SQL under the SQL script
Hello,
in the GRID application you can simply change the sql statement…
In the form application you cannot modify the sql statement but you can choose in [fields positioning] which fields you want to use in the form…
Best regards
Uwe Pfeiffer
scriptcase forms bug with field ending with _type
[QUOTE=Pfeiffer;11750]Hello,
in the GRID application you can simply change the sql statement…
In the form application you cannot modify the sql statement but you can choose in [fields positioning] which fields you want to use in the form…
Best regards
Uwe Pfeiffer[/QUOTE]
I am aware of this function and it is not suitable for the current task, because script case form’s application is still phrasing these fields, even if the fields are hidden. Let me explain my problem.
There is a BUG in scriptcase which interfers with my project. I have lots of fields in my table that have the word _type at the end of the field name “attachment_type”, “id_type” and etc. I cannot rename these fields as another software (third party properitary software) uses the same table as well.
if these field names are present in the table then script case does not run the forms application. The grid application works well.
The only way to bypass the bug in script forms application is to change the field name or remove from the table - both actions unsuitable.
The other idea was to hide the field name from being used in the form application, which is where this post started for.
I see that we can use the database dictionary - can we untick the field tpo hide a field as well?
Thanks for your time
Hello,
Our bugs team is currently aware of this issue, and they are running tests to verifiy if it is a bug or not, and if it is, what might be causing it.
You could get in touch with our support team, they may have a workaround to the problem.
regards,
Bernhard Bernsmann
it is a bug
[QUOTE=bartho;11789]Hello,
Our bugs team is currently aware of this issue, and they are running tests to verifiy if it is a bug or not, and if it is, what might be causing it.
You could get in touch with our support team, they may have a workaround to the problem.
regards,
Bernhard Bernsmann[/QUOTE]
Hi Bernhard,
It is a BUG in version 6.0x 39. Exact same table works in SC version 5.x
Support is aware of the issue. I am trying to work around the problem untill support fixes the issue.
Thanks
Hello,
As soon as I hear from our bugs team, I will get back at you.
regards,
Bernhard Bernsmann
Just a thought, sometimes you can change the statement e.g.:
select attachment_type as attachtp,id_type as idtp from …
That’s correct sql but afaik it cannot be used within SC, or at least on every spot. AFAIK the parser of scriptcase extracting fieldnames does not like this.
There are some other strange behaviour of SC… for example with a database field and the ending <fieldname>_name… This is a confirmed bug older than 2 month and SC support DOES NOTHING to change this… Meanwhile I have 3 bugs concerning field name and SC support doesn’t care…all is posted as a support ticket…
Meanwhile I’m thinking about no longer to use the paid support…
All my bugs are still existing… and I don’t like to pay for a support to tell them THEIR errors and then they let me wait for weeks without a helpful response. Sorry, but that’s the truth.
SC is the best tool I know … but support is still … (:
The always are testing…testing…testing… and they are all working on SC V7 … but we still use V6.
regards
Uwe
This is a very basic request. Removing an existing field from the application.
Scriptcase cant handle this task.
Hello,
Just to keep you guys on the loop, I’m asking for an update on the issue to our bugs team.
regards,
Bernhard Bernsmann
Hello all,
I have yet to receive an update on this issue with version 6.
This bug exists in version 7 as well
Hello,
I’m contacting our bugs team regarding this issue.
regards,
Bernhard Bernsmann
The best approach would be to share mantis with the community. But I know that Mantis is maintained in Portuguese. An option could be to post confirmed bugs in a separate list and keep track of solutions. If that’s a problem I don’t mind to maintain this on our communitysite. If users are willing to share the bugs/issues I can realise this list and communicate with SC. I’ve had a lot of discussions regarding support with SC staff. I know that they are working hard to improve support, but I can see the users argues as i have (had) similar experiences. I agree on the part that SC is a great product, but that support is simply not good enough. I know that you are doing your best and we are trying too, but if SC is able to put it up to a high degree then you have the best product.
I just ran into this problem myself, in Scriptcase v7. I created a form that took me quite a while to get perfected. Then I realized the table it references in the database contained a redundant field, called parent_id. It’s redundant because there’s also a field called sequence_id that does the same thing only more elegantly. So I deleted parent_id from the table. It broke the form. I now get a SQL error when attempting to run the perfected form. I cannot modify the SQL to exclude the field. Am I now stuck recreating the entire form because of this bug?
I’m not sure if it will help, but what kind of sql error do you get? Look at the sql entry to see if the right fields are still primary key. Sometimes this get’s broken causing different kind of problems. I assume you have not forgotten to synchronize (application -> synchronise)?
delete application forms/grids
[QUOTE=madikonda;11784]I am aware of this function and it is not suitable for the current task, because script case form’s application is still phrasing these fields, even if the fields are hidden. Let me explain my problem.
There is a BUG in scriptcase which interfers with my project. I have lots of fields in my table that have the word _type at the end of the field name “attachment_type”, “id_type” and etc. I cannot rename these fields as another software (third party properitary software) uses the same table as well.
if these field names are present in the table then script case does not run the forms application. The grid application works well.
The only way to bypass the bug in script forms application is to change the field name or remove from the table - both actions unsuitable.
The other idea was to hide the field name from being used in the form application, which is where this post started for.
I see that we can use the database dictionary - can we untick the field tpo hide a field as well?
Thanks for your time[/QUOTE]
i agree not to be able to wipe an application away ( a form or a grid ) and start again is a flaw in the design of this application.
only off shore developers would do such a thing.
[QUOTE=madikonda;11784]I am aware of this function and it is not suitable for the current task, because script case form’s application is still phrasing these fields, even if the fields are hidden. Let me explain my problem.
There is a BUG in scriptcase which interfers with my project. I have lots of fields in my table that have the word _type at the end of the field name “attachment_type”, “id_type” and etc. I cannot rename these fields as another software (third party properitary software) uses the same table as well.
if these field names are present in the table then script case does not run the forms application. The grid application works well.
The only way to bypass the bug in script forms application is to change the field name or remove from the table - both actions unsuitable.
The other idea was to hide the field name from being used in the form application, which is where this post started for.
I see that we can use the database dictionary - can we untick the field tpo hide a field as well?
Thanks for your time[/QUOTE]
I know It’s years old this thread. Did it get fixed??? I’ve never encounter this bug (nor I have a table field that’s named as you mention) but maybe, if the bug stills there, you could work around it by creating a “view” in MySQL in where you just take the columns you need from that original table, changing the names of the problematic ones and then constructing the scriptcase app from the view instead of the original table.
This way, MySQL handles the inserts, updates and Selects inside the VIEW definition, and Scriptcase just do it’s thing