Re: [WebDNA] Searching for multiple bits of data in one field or use
This WebDNA talk-list message is from 2016
It keeps the original formatting.
numero = 113023
interpreted = N
texte = 611 I think you should store each alarm condition as one bit in a binary = number long enough to accommodate all alarm conditions. Then, each base = 10 value of that binary number represents a unique alarm or combination = of alarms. > On Sep 29, 2016, at 6:42 PM, dale
wrote: >=20 > I searched the talk archives, though I probably didn't use the proper = search terms. >=20 > The system for work I will be building is kind of like a fleet = management system. It isn't tracking the vehicles, but a computer and = camera system we install and maintain on the vehicles.=20 >=20 > One of the things I wanted to do is to put the various problem codes = (e.g. C HD PCB SSD) in a single field separated by a comma. My thought = is that it would be easier to search for systems that had a specific = problem and/or combination of problems.=20 >=20 > As it has been a few years since coding in WebDNA, I'm not sure if = this is the best way or not. We do come up with new codes as time passes = based on new systems.=20 >=20 > Would you recommend using a single field for various codes as listed = above where I would only have to change the searches or using a hdr file = to make adding additional codes a bit easier? >=20 > I really haven't searched for multiple bits of data in a single field = before.=20 >=20 > Ways in which this would be used: > Someone checking the systems remotely would enter the code for that = system > Techs fixing the system would need to remove the appropriate codes for = what they fixed > Running reports to determine which systems have certain issues >=20 > Additionally, each time the techs create a service ticket to make a = repair, I will save a copy of the the status of the system along with = their notes in a history database so we will have a life-cycle of the = system. Those records would only be editable by certain admin accounts.=20= >=20 > Thank you in advance for any recommendations as to the best way to = handle this.=20 >=20 > Dale >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Associated Messages, from the most recent to the oldest:
611 I think you should store each alarm condition as one bit in a binary = number long enough to accommodate all alarm conditions. Then, each base = 10 value of that binary number represents a unique alarm or combination = of alarms. > On Sep 29, 2016, at 6:42 PM, dale wrote: >=20 > I searched the talk archives, though I probably didn't use the proper = search terms. >=20 > The system for work I will be building is kind of like a fleet = management system. It isn't tracking the vehicles, but a computer and = camera system we install and maintain on the vehicles.=20 >=20 > One of the things I wanted to do is to put the various problem codes = (e.g. C HD PCB SSD) in a single field separated by a comma. My thought = is that it would be easier to search for systems that had a specific = problem and/or combination of problems.=20 >=20 > As it has been a few years since coding in WebDNA, I'm not sure if = this is the best way or not. We do come up with new codes as time passes = based on new systems.=20 >=20 > Would you recommend using a single field for various codes as listed = above where I would only have to change the searches or using a hdr file = to make adding additional codes a bit easier? >=20 > I really haven't searched for multiple bits of data in a single field = before.=20 >=20 > Ways in which this would be used: > Someone checking the systems remotely would enter the code for that = system > Techs fixing the system would need to remove the appropriate codes for = what they fixed > Running reports to determine which systems have certain issues >=20 > Additionally, each time the techs create a service ticket to make a = repair, I will save a copy of the the status of the system along with = their notes in a history database so we will have a life-cycle of the = system. Those records would only be editable by certain admin accounts.=20= >=20 > Thank you in advance for any recommendations as to the best way to = handle this.=20 >=20 > Dale >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Patrick McCormick
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Number of Line Items (1998)
Sorting nested search (2003)
E-mail loop ! (1997)
Re1000001: Setting up shop (1997)
REDIRECT (2001)
Email Set-Up? (1997)
HELP WITH DATES (1997)
Any Unix/Linux version to come? (1999)
[click][/click] (1999)
Need Web Cat Hosting ASAP (2000)
fixed date problem (1997)
anyone have an automated template encrypter? (2000)
[input] questions (1997)
Avery 5160 Mailing Labels SOLVED (2003)
Adding Items to Cart (2003)
Search problem C++ (2000)
[WebDNA] Passing a text variable via copyfile (2019)
WebCatalog can't find database (1997)
OT: Limit on # of Pulldown entries (1997)
Help! WebCat2 bug (1997)