Version imprimable
Salut;
voilà mon nouveau problème!
j'arrive pas à obtenir le numéro d'enregistrement en cours avec RecNo. je travail avec Access version 2003. y'a t-il un autre moyen pour l'avoir.
ce qui j'ai fait correspond à ça :
Code:Label1.Caption := Format('%d / %d', [Table1.RecNo, Table1.RecordCount])
Table1.RecordCount retourne bien le nombre d'enregistrements :yaisse2:
Table1.RecNo retourne toujours -1 :aie:
Merci d'avance.
Je ne suis pas sûr de ce que j'avance, a vérifier :
RecNo ne fonctionne pas si la Table est filtrée.
Re;
je ne suis pas en mode filtrage. ce que je peux confirmer par contre c'est qu'avec les tables Paradox j'ai pas ce problème.
Peut-être une piste du coté API BDE !
J'avais effectivement déjà lu quelquepart que l'utilisation de RecNo (et d'autres propriété du TTable) ne fonctionnait bien que sous Paradox.
Pourquoi ne pas ajouter un champ (à numéro unique) à ta table?
Re;
c'est une alternative mais ça demande une maintenance et du travail en plus.
je suis presque persuadé qu'il existe une fonction API BDE mais....
Utiliser ACCESS par BDE déjà, c'est pas naturel, car cela repasse par le driver ODBC, autant utiliser ADO !
Ensuite, le RecNo fonctionne avec d'autres composant comme TMyDataSet (CoreLab - MyDAC MySQL), mais dans l'implémentation du TTable normalement le RecNo n'est affecté que pour des drivers BDE Natif et non avec les drivers ODBC ...
Enfin, ajouter un champ auto-inc sur ACCESS je ne connais pas, mais justement c'est la meilleur solution, cela rend les données plus stables, plus facilement accessible surtout avec un RequestLive sur lequel est effectué un Edit\Post ...
l'API BDE ne prosera rien de plus pour un Driver ODBC !!!
Re;
merci pour vos réponses mais simplifions les choses, y a t-il un autre moyen pour avoir l'enregistrement en cours sans recourir à la propriété RecNo?
tout en sachant que ma base de données est access 2003 et je travaille avec le composant table.
Si tu as une clé primaire unique, il faut l'utiliser
Si tu n'as pas de clé primaire unique, tu dois avoir des problèmes avec les Edit\Post, ... il en faut une !
Bonsoir,
J'ai testé avec ODBC, ça fonctionne parfaitement là le code
Code:
2
3
4
5
Merci liazidf, comme je le disais cela dépend énormément de l'implémentation du TDataSet ... et tu l'as montré ADO est fonctionnel !
Ce n'est pas difficile de passer de l'un à l'autre, ... tout dépend la "gueule" du code ... si Locate\filter\edit, ... plus délicat, mais si tout en SQL, là c'est tranquille !
Re tout le monde!
Peut-être que je devrais reformuler ma question autrement !
1. j'utilise TTable pas ADOTable dont je sais parfaitement que RecNo ne pose pas de problème ;
2. les routines de MAJ marchent parfaitement, aucun problème au niveau poste, edit ou autre ;
3. pour des considérations de compatibilités (imposées) j'utilise les composants Table.
en d'autre terme, avant l'avènement des composants ADO, comment on faisait pour savoir le numéro d'enregistrement courant, en toute simplicité ?
Donc, sans avoir à définir un champ auto pour lire le contenu qui correspondrait au numéro d'enregistrement courant, avec tout ce que cela pourrait générer de code supplémentaire rien que pour ça.
Peut-être que je suis plus explicite là !
Merci encore une autre fois.
Le RecNo n'a pas de signification en dehors du contexte du DataSet, il est affecté , il correspond à une position dans le curseur BDE pour Paradox (sur un TTable, c'est suivant l'ordre physique des enregistrements mais pas permanent dans le temps, sur TQuery idem, c'est sur une séquence)
Il me semble que pour DBBase, le RecNo est exploitable comme assimilé Clé Primaire mais je n'en suis pas sur
Pour les autres formats cela dépend du driver ...
Par Exemple, tu as un TTable avec 10 lignes, tu supprimes le RecNo 5, et bien misère, tout ce décale, le RecNo 6 devient le 5, le 7 devient le 6 ... voilà, on voit tout de suite la non-utilisabilité d'un tel identifiant !
Dans quel cadre tu veux utiliser le RecNo ?
Mais on l'utilisait pas ! c'est très simple, j'ai toujours conçu mes tables avec un Auto-Inc (avec Paradox c'était ultra simple), et je fixais une clé primaire unique dessus ... il y a des méthodes lorsque l'on développe un logiciel utilisant de la Base de Données, lorsqu'elle ne sont pas appliqués, et bien on est dans la merde !Citation:
en d'autre terme, avant l'avènement des composants ADO, comment on faisait pour savoir le numéro d'enregistrement courant, en toute simplicité ?
Merci à toute l'équipe et tout spécialement ShaiLeTroll
La solution de la clé unique est réalisable et le problème de la suppression ne pose pas de problèmes avec les bases de données access si on fait un compactage de la base de données après l'opération de suppression.
de cette façon mon problème est résolu. mais l'autre question qui s'impose c'est comment utiliser le row du DBGrid comme numéro d'enregistrement courant ? si on arrive à le lire alors pas la peine d'y ajouter un champs à clé unique !
La proprité Row du DBGrid n'est pas accessible sans un cast sauvage en TCustomGrid
Et a encore moins de valeur que le RecNo car il indique dans une grille virtuelle la position de la grille et elle varie en fonction de la position dans le DataSet, c'est totalement émulé, la grille ne contient pas la totalité des données mais juste une fenêtre ...Code:
2
3
4
5
6
7
Re;
en effet j'ai créé une clé unique mais le problème se pose quand j'ai des filtres alors là c'est vraiment du n'importe quoi.
une autre piste svp ?