Jump to content


  • Posts

  • Joined

  • Last visited

chuckiecc's Achievements

  1. I guess perhaps my question is a bit different that your? not sure. Although I would like a datapage to be able to enter this info, OUR concern is that we receive .csv files, with data that needs to be added to a table. Easy enough. BUT the issue for us is that we receive this data multiple times in a day and SOME of the data we receive in a day is already in the table we want to append to. WE have a unique identifier in our records/fields so that we can make sure our data integrity is ensured. So while the import feature works fine and isn't really an issue for us, the ISSUE is that there is no way (that we are aware of) for us to CHECK the records of the proposed upload vs. the data already in the table and either a) identify those records that are duplicates and NOT import them, but import the others, or b) reject the entire file and list WHICH records already exist? or c) allow us to append the data, bu only append the non duplicates So there may be a way to do this with the import tool, but if there is I can't figure it out.. Any ideas anyone?
  2. Jim did you solve this by chance? We have the same issue with the nuance of adding a unique record check for the upload such that IF the record/information exists that one out of the bunch are NOT uploaded, yet the others are allowed.. I don't want to rely on the professional services group, would rather know how it was done if I can ask.. thanks
  3. we manage multiple client programs for them and they perform some tasks. This issue surrounds assigning a serial number to their individual members each week. Providing that those members of the client have accomplished a small task we give them each week answering a few questions. IF they have answered the questions, then they are "qualified" to receive their serial number. If they have NOT answered their questions, then they are "NOT Qualified" to receive their serial number and they cant enter the number in the field.. Works great no issues. If someone shows up to get a serial number, and they are NOT qualified, all they have to do to "fix' this is to log into their portal and answer the questions we give them and then their status changes to "QUALFIED" One more nuance is that we allow the members of the group to answer the questions multiple times. Their "answers" (validation/qualifications") are good for 7 days as set by a parameter. But we let the users "stack up" answers to the questions if they want. It doesn't matter to us which iteration they choose when assigning a serial number to them. only that they have qualified. We need to create a table that shows the administrator of that client two things: 1) those members of their group that are QUALIFIED to get their serial number and, 2) those members who are NOT qualified to get their serial number. but registered in the program. Here is the problem- the individual clients users are either idiots or very clever. They have found a way to exploit our registration system such that they have registered multiple times under multiple alter egos. Why I have no idea in the world. Yet they have. Worst yet is that one member of a client: for example John Smith DOB 1/1/1980 could have registered 4 times! with different emails. Ok kinda hard to prevent that. BUT if John Smith can't remember which alter ego/email address he wants to use/password combination, then he MAY log in to any of his 4 alter egos and answer the questions. Which isn't the worst thing in the world. HOWEVER what has happened in real life is that for sure John Smith has registered 4 times.. BUT for some reason John Smith in 3 alter egos, has properly associated with the specific client group, while his 4th alter ego has NOT properly associated with his Client group. This alter ego is "unassigned". Because we use authentication based display to ensure that a client only sees its members, then if John Smith's alter ego #4 is the one he answered the questions for, he gets to the top of the line and the Client administrator sees his name on the list (3 times mind you) as being NOT QUALIFIED. John Smith KNOWS he has answered the questions. Further frustrating is that John Smith himself has created this issue arguably. So he argues with the administrator, "no I just answered the questions". Which he did, but the administrator can't tell that because they (as the client) can only see those members associated with their individual group. We can't let the system admins from the client see others, and its hard to train a bunch of people to know what to do..!! So how can we solve this? questions- 1) is there a way if one alter ego is properly registered in group "A" for john smith and another alter ego for John Smith carrying the same DOB + first last name and maybe cell number? is registered in another program/group, that we can SHOW the administrator that John Smith is being shown as registered in two groups. THIS WOULD MEAN THAT THE AUTHENTICATION VIEW WOULD HAVE TO HAVE AN EXCEPTION ONLY IF THAT PERSON IS REGISTERED IN MULTIPLE GROUPS TO SHOW WITHIN EITHER ONE OF THOSE GROUPS? Then they could alert John to correct his registration and associate his 4th alter ego with the proper group. 2) we are having a hard time showing those members of a group that are qualified to get their serial number and those that are not on the same table. We are told by support that this is because our account does not support cascading tables and we have to upgrade to get that which is prohibitively expensive for us as a small company. We temporarily solved this somewhat by giving a tab one with all members of the group and the other one with those of the group that are qualified. But it would be nice to combine those into one table would be preferred. 3) we ARE able to build a table that shows both qualified and not qualified at the same time, but doesn't parse out multiple views or multiple identities/alter egos.. Is it possible to have some type of filter that shows in this table ONLY one alter ego for someone with the same DOB + first + last name for example so that IF There are 4 alter egos registered, only one will show such that our data downstream over time becomes more streamlined? but this then brings into play the issue of john smith above, having 4 alter egos. If we show one, then the one that he happens to log into that week will need to be the one that shows. UGH WE have so many users now like this and so much historical data frankly its a bit of a mess. We have tried to employ measures to narrow the multiple alter ego/registration going forward but honestly don't think we can clean up what we have.. Any ideas here would be most welcome' thanks
  4. We are looking for an api that will behave with Caspio to validate Emails when our users register. We have successfully gotten dbounce to work, however the validation 'check' renders above the header on our datapage and we cannot move it to elsewhere in the page no matter what we try. Can someone help with this or, reccomend an api that behaves better with Caspio? easiest/cheapest/best etc../fastest thanks
  5. we are trying to figure out if Caspio is an option for us and need to capture barcode values into a web based Caspio form.? Currently we are using jotform to capture that data which works fine, but we need to manipulate that data, which is a shortfall we have in jotform. how would we use Caspio to capture the information off of barcodes using the native scanners in cell phones mobile devices. thanks
  • Create New...