Another ..Error[8]

E

Eugenio

Guest
Debbie Sontag wrote:

> I'm getting the same errors. I had an existing access
> database that was sent to me to have "converted" into a web
> database. I converted the data and imported it into a database
> table. Then I proceeded to create additional tables for the
> select fields like I had done on a previous installation of
> Dadabik (v2.x). When linking the sub-table to the main table,
> I did so using the data column as the select column because
> there was already data entered into the fields on the main
> table. Long story short - it worked like a charm in older
> version. As a side note, I have to have the data pulled into
> the main table by way of the actual data column not the
> record/id column because users will be exporting the data to
> CSV to create reports/charts from it.
>
> I tried to do the same thing in v3 and am having a real
> problem getting the link between the two tables to work.

[....]

You should post here the structure of your DB otherwise it is difficult to understand where the mistake is.



(Latest version of DaDaBIK when this message was posted: 3.0 beta)
 
D

Debbie Sontag

Guest
Eugenio

Here is the structure of the main table that calls the data from the other tables:

Problem_List
Field Type Attributes Null Default Extra
ProblemID mediumint(12) No 0 auto_increment
ProblemTitle varchar(50) No
ProblemType varchar(50) No
Application varchar(50) No
SeverityLev varchar(50) No
PriorityLev varchar(50) No
TestLev varchar(50) No
SysFunctionTested varchar(50) No
BusFunctionTested varchar(50) No
DateOpened date No 0000-00-00
OpenedBy varchar(50) No
FoundBy varchar(50) No
VersionFound varchar(50) No
TestCaseID varchar(50) No
ProblemDesc blob No
CauseCode varchar(50) No
CauseDesc blob No
ChangesReq blob No
StatusCode varchar(50) No
StageCode varchar(50) No
Owner varchar(50) No
ActionDate date No 0000-00-00
EstTimeCorrect varchar(50) No
ResolveType varchar(50) No
DateUpdated datetime No 0000-00-00 00:00:00
UpdatedBy varchar(50) No
DateClosed date No 0000-00-00
ClosedBy varchar(50) No
VersionResolved varchar(50) No
DateValidated date No 0000-00-00
CloseComments blob No
DateQATest date No 0000-00-00
ReviewType varchar(50) No


Indexes : Keyname Type Cardinality Field
PRIMARY PRIMARY 141 ProblemID
ProblemID UNIQUE 141 ProblemID


Here is one of the tables providing data to the main table above (they are all structured the same way):

applications
Field Type Attributes Null Default Extra
record mediumint(8) No 0 auto_increment
Application varchar(50) No


Indexes : Keyname Type Cardinality Field
PRIMARY PRIMARY 9 record


Here is the error I get when calling the table:

[08] Error: during query execution.
SELECT Application FROM applications WHERE Application = Headend
MySQL server said: Unknown column 'Headend' in 'where clause'

'Headend' is one of the entries in the applications table but here it thinks it is a column heading.

Does this help at all? If you need more data, just let me know what I should provide.

Thanks!
Debbie
 
E

Eugenio

Guest
Debbie Sontag wrote:

> Eugenio
>
> Here is the structure of the main table that calls the data
> from the other tables:

[....]

The corresponding settings of Problem_List should be:

Primary key field: Record
Primary key table: applications
Linked fields: Application



(Latest version of DaDaBIK when this message was posted: 3.0 beta)
 
D

Debbie Sontag

Guest
OK, however, I still get errors:

[08] Error: during query execution.
SELECT Application FROM applications WHERE record =
MySQL server said: You have an error in your SQL syntax near '' at line 1


Is this because there is an error in the SQL syntax or because there is already data in the table? For example: existing record has data in the field, however, future records are to be populated with data from applications table. In order to use this version will I have to go through entire database and change all the fields to the numerical record number? If so, how does this make the information useful if saved to excel or csv for sorting, etc, after the fact?

Still using previous version.

Debbie
 
E

Eugenio

Guest
Debbie Sontag wrote:

> OK, however, I still get errors:
>
> [08] Error: during query execution.
> SELECT Application FROM applications WHERE record =
> MySQL server said: You have an error in your SQL syntax near
> '' at line 1
>
>
> Is this because there is an error in the SQL syntax or
> because there is already data in the table? For example:
> existing record has data in the field, however, future records
> are to be populated with data from applications table. In
> order to use this version will I have to go through entire
> database and change all the fields to the numerical record
> number?

Yes you need the ID in the main field.

>If so, how does this make the information useful if
> saved to excel or csv for sorting, etc, after the fact?

The export to csv feature automatically convert the ID with the correct display values.

(Latest version of DaDaBIK when this message was posted: 3.0 beta)
 
D

Debbie Sontag

Guest
AAARRGGHH!
Still no go. Changed ENTIRE main table so the ID's of the record field were in place instead of the display data. Configured the thing to reference the record/id field and still getting this error:

[08] Error: during query execution.
SELECT Application FROM applications WHERE record = Headend
MySQL server said: Unknown column 'Headend' in 'where clause'

There is no column 'Headend' in the table the data is coming from - it is one of the records in that table. I don't know what else to do at this point. Actually, because I cannot link one database in more than one location with this version, I may not update this particular database at all now. There are several fields where the data comes from a team_members table - can't reference/link to a table more than once so I cannot use this for this particular case.

Maybe another database request will come in that I can play with V3 on. Oh well.

Debbie
 
E

Eugenio

Guest
Debbie Sontag wrote:

> AAARRGGHH!
> Still no go. Changed ENTIRE main table so the ID's of the
> record field were in place instead of the display data.
> Configured the thing to reference the record/id field and still
> getting this error:
>
> [08] Error: during query execution.
> SELECT Application FROM applications WHERE record = Headend
> MySQL server said: Unknown column 'Headend' in 'where
> clause'
>
> There is no column 'Headend' in the table the data is coming
> from - it is one of the records in that table. I don't know
> what else to do at this point. Actually, because I cannot link
> one database in more than one location with this version, I may
> not update this particular database at all now. There are
> several fields where the data comes from a team_members table -
> can't reference/link to a table more than once so I cannot use
> this for this particular case.
>
> Maybe another database request will come in that I can play
> with V3 on. Oh well.

Post here (or send directly to me if tables contain private infos) the dump of your dadabik tables and the tables you want to manage with DaDaBIK (including data, just a few records is enough).



(Latest version of DaDaBIK when this message was posted: 3.0 beta)
 
E

Eugenio

Guest
Debbie Sontag wrote:

> AAARRGGHH!
> Still no go. Changed ENTIRE main table so the ID's of the
> record field were in place instead of the display data.
> Configured the thing to reference the record/id field and still
> getting this error:
>
> [08] Error: during query execution.
> SELECT Application FROM applications WHERE record = Headend
> MySQL server said: Unknown column 'Headend' in 'where
> clause'
>
> There is no column 'Headend' in the table the data is coming
> from - it is one of the records in that table. I don't know
> what else to do at this point. Actually, because I cannot link
> one database in more than one location with this version, I may
> not update this particular database at all now. There are
> several fields where the data comes from a team_members table -
> can't reference/link to a table more than once so I cannot use
> this for this particular case.
>
> Maybe another database request will come in that I can play
> with V3 on. Oh well.

Post here (or send directly to me if tables contain private infos) the dump of your dadabik tables and the tables you want to manage with DaDaBIK (including data, just a few records is enough).



(Latest version of DaDaBIK when this message was posted: 3.0 beta)
 
D

Debbie Sontag

Guest
Interesting ...

I changed line 2882 to read:

$sql .= " FROM ".$quote.$primary_key_table_field.$quote." WHERE ".$quote.$primary_key_field_field.$quote." = '".$quote.$field_value.$quote."'";

and my data now displays in V3 with no error messages!

Just one more problem now ... the Applications column still does not display in the results view (shows empty table cells) although the data is there and does display properly on the details view page.

Eugenio - any ideas why the data/contents will display on one view and not the other? I have this field set to display on all views in the interface configuration.

Thanks!
Debbie
 
E

Eugenio

Guest
Debbie Sontag wrote:

> Interesting ...
>
> I changed line 2882 to read:
>
> $sql .= " FROM ".$quote.$primary_key_table_field.$quote."
> WHERE ".$quote.$primary_key_field_field.$quote." =
> '".$quote.$field_value.$quote."'";
>
> and my data now displays in V3 with no error messages!
>
> Just one more problem now ... the Applications column still
> does not display in the results view (shows empty table cells)
> although the data is there and does display properly on the
> details view page.
>
> Eugenio - any ideas why the data/contents will display on one
> view and not the other? I have this field set to display on
> all views in the interface configuration.

Hi Debbie,
I've received your dumps. Yes, if you apply that change (the same I've described here:
http://www.dadabik.org/forum/read.php?f=1&i=2365&t=2365
this morning) no more errors will be displayed.
The problem is with the application coloumn because (and it is the second 3.0 bug I've discovered using your dump) the field name "application" exists both in the main table and as a linked field in a linked table.

So for the moment the only workaround is to change the name of one of the field, waiting for the next release of DaDaBIK in which the bug will be fixed.
Thanks for having reported the bug.

(Latest version of DaDaBIK when this message was posted: 3.0 beta)
 
You must log in or register to reply here.
Top