jajajaj... que bueno...

es como si me obligan a declarar los sueños que tuve anoche, una payasada...

Disiento de esto.

Cuando se quema algo hasta la extenuación, ya no queda nada por arder... Si dos tribus luchan entre ellos hasta la extinción, cuando una de ellos se extinga se acabó la lucha.
Ahora bien, esa sería la solución 'matemática', humanamente inaceptable.

El problema de los radicales es doble. Están los cabezas vacías que son los 'ejecutores', que es gente con la mente retorcida, la mano que ejecuta y están los cabezas envenenadas, que son los que incendian el alma de esa gente.

El terrorista que al final estalla una bomba, probablemente no sepa gran cosa de la vida, y esté tan harto de vivir que no le importe morir. A estos basta educarlos...
Los que inflaman los corazones esos son los malvados que habría que eliminar, pero no figuran sus nombres en parte alguna. aunque en realidad sabemos que se sientan en sofás muy cómodos en Arabia Saudita (por ejemplo), y que ni pasan hambre ni nada, más bien nadan en petróleo y les interesa crear tensión internacional, porque eso dispara los precios del petróleo (qeu es la auténtica realidad tras todo el asunto, subir precios), y a ellos se la suda que 4 pardillos barriobajeros maten a algunos occidentales y luego mueran o los encarcelen... para manipularlos que mejor que engatusarles con sus creencias, así se ahorran pagar mercenarios, lo hacen gratis y para colmo 'contentos' (no se puede ser más 61L1P0LL45)...

Cuando el petróleo sea completamente eliminado como recurso energético, todo esto será cosa del pasado. Así que mi apuesta más prácitca va por forzar las energías renovables YA, URGENTE, SIN DEMORA.

La energía es vibración. Todo late, porque todo está compuesto de partículas que en última instancia están sujetas a fuerzas de interacción internas y externas.

Que no podamos medir fuerzas minúsculas obedece a que no puede construirse un aparato más pequeño de aquello que mide, si no se hace con aquello que lo mide, con lo cual cómo diferenciar de si la medición es real, o generada por el propio aparato? (y es ahí donde entra el gato de Schrodinger, en la miniaturización hasta el punto de que lo observado se ve alterado por aquello que lo observa) . Por mirar Marte con un telescopio no vas a alterar Marte, pero si el telescopio es del tamaño del Sol, evidentemente alterará Marte. No es distinto de la gravedad y la distancia que separa dos objetos... la distancia y la masa, señalan la atracción que entre ellos haya. Igualmente cuando lo magnitud de lo que observa es significativamente grande en comparación con lo observado, la influencia se produce.

Incluso en el cero absoluto, dudo que sea absoluto, y alguna vibración debe haber, de otro modo, si no fuera así, sería inalterable (eternamente).

Una báscula podrá pesar muchas cosas, pero jamás podrá pesarse a sí misma. Se parte siempre del hehco  de que la báscula ha sido pesada por otra báscula, o al menos la parte de la báscula que pesa sobre las partes que no se alteran con el peso.... Este mismo problema se tiene con todo, cuando el tamaño no es asequible, puede descartarse cuando ese valor es despreciable, pero no cuando ese valor es tan influyente que altera el propio sistema observado.

No está mal, pero no acabas de ceñirte a las especificaciones que te han dado.

Por ejemplo, para los cocineros se especifica esto:
Pero luego en el diagrama para los cocineros, no especificas restaurante (dodne trabaja)
Entonces el cocinero debería tener un campo "Foreign Key Cod_Restaurante", en el que el cocinero opera. Ahora mismo si miras un cocinero, no sabes donde trabaja.

Del mismo modo te faltan listas.... más simples una lista es una tabla con un solo campo , por ejemplo te falta una lista de cocineros, de restaurantes, de menús... así yo modificaría tu tabla de "Menus"


Y luego tienes otra tabla de detalles de cada menú:

_

Cuando de un dato hay muchos, creas una lista (una tabla de Ids (códigos), que referencian luego a otra tabla con todos los detalles que se precisen.
Así la tabla para buscar es muy rápida y sencilla y una vez encontrado el código, se usa para ir a al tabla de detalles (si se precisa tomar más info que sólo la existencia).

- De igual modo habría que proceder con la tabla cocineros, dividiéndola en dos, en una solo la lista de códigos de cocineros y en otra los detalles de cada cocinero.
- Lo mismo con la tabla restaurantes, una tabla sólo con los códigos y otra con los detalles de cada uno.
- Ídem con los proveedores.
- Como también te piden restaurantes por ciudades:
puedes tener, el campo Ciudad en la tabla tblRestaurantesDestalles.

En cambio las recetas, salvo que un mismo menú tenga diferentes recetas (y esto suceda con muchísimos menús), yo la descartaría. En su caso ese sería un campo en la tabla tblMenuDetalles.
Ingredientes() es un array, dentro de menús que podría referenciarse conforme al campo NumIngredientes, cada Ingrediente puede disponerse como una pareja de campos, para otra tabla:
Incluso podría ponerse un tercer campo: un FK Cod_Menu, para saber en qué menú aparece este ingrediente en esa cantidad... No obstante quizás sea demasiado detallar si no se ha especificado expresamente, pero la menos si lo siguiente:

Donde producto es Cod_Producto (ó Cod_Ingrediente).
La razón de esto, es que con ello se puede al mismo tiempo llevar la cuenta de existencias y consumo de ingredientes y por tanto facilitar hacer un pedido cuando esté próximo a agotarse...

Por tanto te faltaría también dos tablas:


y bueno, mirándolo así por encima básicamente esa es la idea... pero no lo tienes mal, aunque se puede mejorar en la forma indicada...


 

Para casos como el que comnentas, lo más sencillo es asignar un valor numérico que denote que el usuario a cancelado. en tu caso podría ser un valor 0.
Es decir:

Ingrese otro número (0 para finalizar): 56'3

Entonces tu detectas si se entró "0" u otro valor... considera también como 0, un valor no procesable como número, por ejemplo:

Ingrese otro número (0 para finalizar): hola

Hace ya mucho que no actualizo una BIOS... peor he actualizado muchas y en algunos equipos varias versiones.

En general:
Antes te descargabas desde el fabricante dos cosas: el programa flasheador, propiamente y la copia de la verión que ibas a instalar.
Y los pasos a seguir eran:
1 - Tomabas un diskette (era laforma antigua), y lo formateabas como un diskette del sistema (con el comando Sys, que transfería ciertos ficheros de arranque y así lo dotaba como "bootable"
2 - Luego se copiaban ambos ficheros descargados. Había que asegurarse que todavía sobraba espacio o bien disponer de una segunda disquettera (o acceso a la unidad de disco duro durante esa fase, no todos los BIOS "veían" tu disco duro).
3 - Arrancar desde diskette, lo que a menudo suponía el paso previo de reiniciar y entrar en la BIOs, para configurarlo así (entonces no había un sistema de parada para elegir el dispositivo de arranque, como hoy casi incluyen todos aunque no se suelan usar).
4 - Arrancar el programa flasheador. Este no hace un reconocimiento básico durante ese arranque (realmente los programadores de BIOS, son programadores de segunda clase, por no llamarlos mediocres directamente, pero afortunados de tener la decripción completa del sistema para poder programarlos).
5 - Dentro de las opciones, lo útil era pedirle que antes quieres hacer una copia al diskette/disco duro de la versión del BIOS actual (por si el nuevo no va bien).
6 - Proceder a sobrescribir el BIOS con la nueva versión. Típicamente era un comando del programa flasheador, similar a:  flash.exe /n "a:\fkr760.BID"
venían extensiones peregrinas para los ficheros. algunos más sofisticados tenían un menú que te permitían elegir que quieres actualizar en la BIOS, y muy pocos te dejaban elegir el idioma.
Al menos la mayor parte de las veces si el BIOS no era correcto, te informaba y no lo sobrescribía. O también te informaban si la versión a instalar era menor que la actual, y te pedía confirmación... pero esto no siempre.

En la actualidad, ha mejorado el modelo, pero sigo pensando que son los programadores más retrasados quienes diseñan estos programas, porque básicamente siguen siendo igual de malos.
Descarta actualizar desde la red, es el modo más fácil de que falle. Si descargas copia, mira si en la web viene el hash del mismo para asegurarte que coincide.
aunque no las necesites, o creas no necesitarlo, bájate todas las versiones y guárdalas. nunca sabes si una versión anterior era más estable que una actualización posterior. A veces arreglan un fallo que no se aplicaba a tu caso, pero dejaban otro fallo que si se aplica a tu caso.
No es que sea preciso instalar todas las versiones una tras otra, porque si no falle la actualización, no, la razón para ello, es que cuando veas que corrige el problema que tienes, pares la actualización... aunque no estés en la última versión. Si como digo conviene descargar todas las actualizaciones que haya en la web para tu sistema, porque pasados x años, desaparecen y ya no tienes opciones. eso sí, renómbralas en corto, y refleja perfectamente su versión.

Ahora casi todos los sistemas permiten recuperar la BIOS si falla. Incluso hace 30 años, en algunos sistemas era posible al menos resetearlo al estado original de fábrica, operando sobre algún jumper en la placa base. Para todo ello es imprescindible un manual de la placa base (de esos de 300 páginas, no esos de especificaciones básicas de 30 páginas).

Deja copia de la ROM que vas a instalar, en el disco duro, aparte de en el USB desde el que quieras arrancar (es preferible así). Si la propia BIOS incluye el programa para actualizar la BIOS, simplemente te pedirá que elijas el origen de la ROM, hará un breve chequeo para comprobar que esa ROM, pertenece al equipo y alguna más y hará la copia.

Como sugerencia te indicaría que antes de proceder, pongas los valores por defecto en la BIOS (guarda en papel las opciones que tienes actualmente si tienes dudas de configurarlo luego como lo tienes ahora), ya que dudo mucho que las ROMs sean probadas a fondo, con diferentes opciones en activo en el BIOS. Luego de actualizada, vuelve a configurarlo como lo tenías.
También te recomiendo que si tiene opción de guardar la BIOS actual, lo hagas antes de actualizar.
Si el BIOS presentara muchas opciones de actualización, esto es poder elegir diferentes áreas para actualizar, la que menos interesa es el bloque de datos del usuario.

¿qué se puede esperar cuando un tonto entra en un laboratorio?. Que crea que es una 'nevera' más grande que la de su casa... Es lo único capaz de ver, muy grande y muchos recipientes, no puede ver más.

Y ya desde ahí, viendo el tamaño, pedirá un yogur y cuando le digan que no, se quejará alegando que: "pués vaya la nevera de mi casa es mucho más pequeña y siempre tengo yogures, o la de cualquier amigo o conocido que tengo".

La ignorancia supina, los hace ser valientes.

No es buena idea que un sistema que deba hacer loogin, permita dejar el usuario escrito.
Un buen sistema cuando falle la contraseña, debería borrar el usuario y la contraseña (o no borrar el usuario), pero al menos SIEMPRE indicar que "el usuario, la contraseña o ambos no son correctos.". Por que indicar que el 'usaurio no existe' o 'contraseña incorrecta' es dar pistas... Ya se sabe que quienes diseñas estas cosas muchas veces tampoco tienen un mínimo de consideración con la seguridad, o bien son forzados por aquello de: "...hazlo para usuarios torpones." 

Entonces lo que pides, podrá o no ser posible, en base a cómo se haya diseñado el sistema de login.

Piénsalo un poco, es como si le dijéramos a los fabricantes de cerraduras: "Oye cuando rompa el muelle que sujeta cierta pieza de la cerradura, por favor, no solteis la alarma hasta que no corte el cable, de la alarma que hay un poco más allá del muelle"... y naturalmente más 61L1P0LL45 aún, si los fabricantes hacen caso.

La ayuda no es correcta proporcionarla sin saber como te va a ayudar.

Mejor indica como tienes pensado aocmeterlo y desde ahí se ve si el enfoque que llevas es válido, correcto, tiene defectos, qué fallos o complejidades te encontrarás, etc...

Cuéntanos, tu enfoque primero, así la ayuda será precisa y no genérica.

No es habitual tener que retener entradas fallidas. si son fallos se aporta info y se devuelve un error y listo. Si el sistema es desatendido y no va a estar presente nadie  (o no conviene dejar al programa en espera por una interacción con el usuario), simplemente se escribe un log y listo.

Indistintamente de que una clase provea o no una cola y un manejo profundo de la cola, nada le impide a uno, generarlo si lo precisa y en ese caso basta que el sistema provea exclusivamente la entrada actual (quiero decir que con que solo provea eso nos es suficiente, y ya aportaríamos nosotros el resto).

El siguiente pseudocódigo procesa entradas (de una forma muy simple) mientras el buffer del sistema nos provea de ellos. aunque se supone que lo correcto es que haya una suscripción a un evento del sistema que avisa automáticamente cuando esto sucede.



Da igual si usas una lista enlazada o una pila... básicamente una pila es una estructura ligera pensada para contener pocos ítems e introducirlos y rescatarlos en un orden específico. Ese orden también puede manenerse con una lista enlazada, aunque no tan evidente como la pila, sin embargo una lista enlazada está pensada para mantener una cantidad indefinida de elementos, una pila en general requiere especificar cuantos elementos ha de tener...

La cuestión, es que si mantienes aparte un buffer de fallos, la pregunta es para que lo quieres, es realmente necesario????.  Y más aún, es la forma correcta retener sólo los fallidos y no todos desde el primer fallo?, etc... (etc = surgen muchas más preguntas, que no es preciso enumerar y que hay que responder). Un breve comentario, para hacerte reflexionar...

Imagina un usuario que abre un vídeo, este está ultracomprimido y tarda en cargarse, mientras el usuario, pulsa 'play' 'avance hasta x posición', luego 'pausa', luego 'volumen +', luego 'fullscreen', luego como todavía no responde, pulsa 'stop'... Puede optarse por guardar todas esas acciones y procesarlas en ese mismo orden cuando se haya completado la carga del vídeo... pero ahora imagina el mismo caso con un menú... uno lo despliega y pulsa 'play', no responde, lo despliega nuevamente y pulsa 'play' , luego 'pausa', luego otra vez 'play'...etc... en este caso puede no interesar procesar cada entrada, ni mucho menos guardar en un buffer todos los fallos...

esto es, si uno considera que se deben procesar, o se procesan todos en el orden en que se producen o tras un fallo, hay que investigar que produce el fallo y en tal caso decidir, si abortar todo o bien guardar todos desde el fallo 8incluído la entrada con fallo) y esperar (si procede), para luego volver a intentar procesarlo todo desde ese punto.

La cuestión es que 'play', 'pausa', 'stop':
- A - Solo deben ser procesables si hay un vídeo cargado.
- B - Guardar al búffer si hay un vídeo cargándose.
- C - E ignorarlas por completo si no hay un vídeo cargado....
Incluso podría simplificarse para incluir B en el caso C.
Y por su parte cuando se carga un vídeo (al completarse la carga), debe verificar si hay un buffer de entradas sin procesar, y en consecuencia lanzar un evento para comunicar que ya está disponible para las entradas 'play', 'pausa' 'stop'...
en cambio fíjate que la entrada 'volumen +' y 'volumen -', se pueden ejecutar independientemente de si el vídeo está listo o no... y aunque sean entradas en medio de las otras. Al caso se provee otro parámetro asociado a cada entrada, que indica si  es prioritario su ejecución es ignorable, o encolable...

Si las entradas de esas acciones fueran del modo 'P' para pausa, 'Y' para 'play', 'S' para 'Stop', 'V' para 'volumen +' y 'v' para 'Volumen -', y 'L' para 'Cargar vídeo' y 'D' para 'Descargar vídeo' tu debes mantener si 'L' ha sido procesado ya o no, 'D', deshabilita 'L'. Tras un fallo debes hacer un segundo procesado en base a su 'priorización', y en este caso ver el estado de 'L'...

En fin, uno debe saber que entradas pueden ser procesadas y cuales no... pero espero que esto te haga reflexionar para encontrar la solución adecuada que necesites.