Calendar Drag & Drop Bugg ??

Scriptcase 7 Bugs
,
#1

I have a field (text) in the DB where I store a time value. In this case it has to be in format hh:mm

I set a calendar application and use the display hh:mm and internal format as hh:mm

The value is correctly saved when a new entry is done.

However, when we use Drag & Drop the value inserted in the database is 11:00:00, so it adds the seconds.

in this particular case (an android app fetches the values from the online mysql db), the field has to be text and the format has to be hh:mm

So if we define the start time format as hh:mm when we drag & drop the same format should be maintained.

Is there any quick solution ? as this is preventing me to advance with buying SC, as it totally prevents the android app to operate with the DB as the field is not in the correct format.

Thanks

#2

What db are you using? I know it adds the seconds but I’m using MySQL and the dateformat of the database is hh:mm:ss. So the format in PHP is only used as a display format. Not the storage format. With SQL it should be able to retrieve the data in hh:mm format I think.

#3

Hello,

Have you tried to activate debug mode to see how your data is being sent to your database?

regards,
Bernhard Bernsmann

#4

The DB is Mysql, but the field in the DB is TEXT, not TIME, and unfortunately it can not be changed to TIME as another app (an android app) is already prepared to work like this.

It works OK with a new insert. Only fails on Drag & drop, which does not respect the configuration we’ve set up for the time field in scriptcase

#5

That is a problem imho. Because the events are not firing afaik. You cannot use the onvalidate to correct your data when you move your appointments. I am searching for a workaround to prevent appointments to go into the weekend. On the form I can prohibit, but if you store it on friday you can move the appointment on the calendar freely anywhere… Similar cause I guess.

#6

As far as I can see, the Drag & Drop feature should respect the definitions of time, date, etc we’ve setup for the field.

#7

Yes and no. If allowed then it should be so. But in general I think that the types should be time and sc should not allow otherwise.